public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Van Hensbergen <ericvh@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	smfrench@austin.rr.com, hch@infradead.org,
	Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: [RCF] [PATCH] unprivileged mount/umount
Date: Wed, 4 May 2005 09:51:17 -0500	[thread overview]
Message-ID: <a4e6962a0505040751359025e5@mail.gmail.com> (raw)
In-Reply-To: <E1DTKkd-0003rC-00@dorka.pomaz.szeredi.hu>

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

  reply	other threads:[~2005-05-04 14:51 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-03 14:31 [RCF] [PATCH] unprivileged mount/umount Miklos Szeredi
2005-05-03 17:30 ` Bill Davidsen
2005-05-04 13:08 ` Eric Van Hensbergen
2005-05-04 14:21   ` Miklos Szeredi
2005-05-04 14:51     ` Eric Van Hensbergen [this message]
2005-05-04 15:21       ` Miklos Szeredi
2005-05-11  8:51     ` Christoph Hellwig
2005-05-11 10:31       ` Miklos Szeredi
2005-05-12 21:08         ` Bryan Henderson
2005-05-13  5:47           ` Miklos Szeredi
2005-05-13  7:19             ` Jan Hudec
2005-05-13  8:33               ` Miklos Szeredi
2005-05-13 23:09                 ` Bryan Henderson
2005-05-14  6:58                   ` Miklos Szeredi
2005-05-16 18:35                     ` Bryan Henderson
2005-05-14 11:49                   ` Jamie Lokier
2005-05-04 13:47 ` Martin Waitz
2005-05-04 14:34   ` Miklos Szeredi
2005-05-11  8:53   ` Christoph Hellwig
2005-05-11  8:48 ` Christoph Hellwig
2005-05-11 10:20   ` Miklos Szeredi
2005-05-16  9:34     ` Christoph Hellwig
     [not found] <406SQ-5P9-5@gated-at.bofh.it>
     [not found] ` <40rNB-6p8-3@gated-at.bofh.it>
     [not found]   ` <40t37-7ol-5@gated-at.bofh.it>
     [not found]     ` <42VeB-8hG-3@gated-at.bofh.it>
     [not found]       ` <42WNo-1eJ-17@gated-at.bofh.it>
2005-05-11 16:41         ` Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>
2005-05-11 17:07           ` Jamie Lokier
2005-05-11 18:49             ` Miklos Szeredi
2005-05-11 19:05               ` serue
2005-05-11 19:46                 ` Bodo Eggert
2005-05-11 20:40                   ` Miklos Szeredi
2005-05-11 21:11                 ` Jamie Lokier
2005-05-12  3:05                   ` serue
2005-05-11 19:35               ` Ram
2005-05-11 20:31                 ` Miklos Szeredi
2005-05-11 21:28                 ` Jamie Lokier
2005-05-11 22:42                   ` Ram
2005-05-11 22:58                     ` Eric Van Hensbergen
2005-05-12  1:02                       ` Jamie Lokier
2005-05-12  2:18                         ` Eric Van Hensbergen
2005-05-12  6:45                           ` Jamie Lokier
2005-05-12 13:23                             ` Eric Van Hensbergen
2005-05-12 13:47                               ` serue
2005-05-12 15:16                               ` Jamie Lokier
2005-05-12 12:51                                 ` serue
2005-05-12 18:51                                 ` Miklos Szeredi
2005-05-12 19:56                                   ` Jamie Lokier
2005-05-13  8:55                                     ` Miklos Szeredi
2005-05-13  1:10                                   ` Ram
2005-05-13  6:06                                     ` Miklos Szeredi
2005-05-13  7:25                                     ` Ram
2005-05-13  8:59                                       ` Ram
2005-05-13  9:10                                         ` Miklos Szeredi
2005-05-13 16:53                                           ` Ram
2005-05-13 17:14                                             ` Miklos Szeredi
2005-05-13 18:44                                             ` Alan Cox
2005-05-13 20:56                                     ` Bryan Henderson
2005-05-12  0:59                     ` Jamie Lokier
2005-05-13  6:41                       ` Ram
2005-05-11 21:09               ` Jamie Lokier
2005-05-11 21:20                 ` Miklos Szeredi
2005-05-11 21:32                   ` Jamie Lokier
2005-05-11 19:32             ` Bodo Eggert
2005-05-11 21:23               ` Jamie Lokier
2005-05-11 21:34                 ` Miklos Szeredi
2005-05-11 21:36                   ` Jamie Lokier
2005-05-12  3:08                     ` serue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4e6962a0505040751359025e5@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=smfrench@austin.rr.com \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox