lkml.org 
[lkml]   [2005]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RCF] [PATCH] unprivileged mount/umount
On 5/4/05, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> Where did you see 10 as the limit? The initial global limit is zero,
> the initial per-user limit is infinity (I did actually test these ;)
>

The verdict is: I should stop trying to read code before I've had my
coffee in the morning. Sorry about that.

>
> > My major complaint is that I really think having user mounts without
> > requiring them to be in a user's private namespace creates quite a
> > mess. It potentially pollutes the system's namespace and opens up the
> > possibility of all sorts of synthetic file system "traps". I'd rather
> > see the private namespace stuff enforced before enabling user-mounts.
>
> Yes, I see your point. However the problem of malicious filesystem
> "traps" applies to private namespaces as well (because of suid
> programs).
>

I'm not sure I quite get this (perhaps I haven't had enough coffee
yet...hmmm). There are, of course, multiple potential vulnerabilities
here -- but if you confine a user's modification to a private
namespace, system daemons and other users would be safe unless they
explicitly suid to the user and we had the per-user namespace
semantics that are being discussed in the other thread.

So, two comments here - if the per-user namespace semantics exist and
someone/something suid's to that user - they make themselves
vulnerable. I imagine there are numerous traps you can set for
someone that suids to your profile. Do any of the system daemons
actually do this?

The other comment is that this is why I don't like per-user namespaces
- per process namespaces avoid this vulnerability. However, that
discussion is already being covered to some length in the other
thread, so I don't really want to go into it again here.

> ...

I don't like any of the proposed solutions. Invisible mounts just
aren't the right solution. Restricting suid/sgid in a cloned
namespace seems like it would be impractical and cause lots of
problems.

Viro - you put in the private namespace stuff originally, and use it
from a user-context (binding your bin directories and what not).
What's your vision on this? What do we need to do to make user
mounts/binds/private-namespace a reality?

-eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-04 16:55    [W:0.948 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site