linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: Eric Van Hensbergen <ericvh@gmail.com>, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call
Date: Wed, 20 Apr 2005 13:03:40 +0100	[thread overview]
Message-ID: <20050420120340.GC10167@mail.shareable.org> (raw)
In-Reply-To: <20050420102711.GR13052@parcelfarce.linux.theplanet.co.uk>

Al Viro wrote:
> On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote:
> > For FUSE, what's needed is that a user can mount something, and the
> > mounted fs is visible only to that user, but it's visible to _all_ of
> > the user's processes.
> 
> So get that namespace as soon as you log in.

Yes.  How?

It is usual to log in on multiple terminals.  You'd _usually_ want
virtual filesystems mounted in one terminal to be visisble in others.

Hmm.  A fairly radical change to the login process would be able to do
it: have login pass the terminal file descriptor to a per-user process
which spawns user login shells from a common namespace.

That would work with the current CLONE_NEWNS mechanism :)

It's quite a radical change to the way logins are done, though.

> > We think namespaces are a nice way to do that: making a user-owned
> > filesystem only visible to a user.  But the mechanism of CLONE_NEWNS
> > does not work, because it presumes namespace divisions are only
> > propagated over parent-child divisions, like environment variables.
>  
> > What we really want is a mount point that propagates across all the
> > processes owned by one user, but is not there for other users.
> 
> This is almost certainly bogus.  Same user can easily want several
> different environments set on the same box.

I agree, but didn't say that before as the explanation is complicated
enough.

It shouldn't be literally per-user - it should be possible for a user
to have several environment _when_ they want that.  chroot-jail style
virtual server environments require that too.

But that shouldn't be the only option - because it would be horrible
to use.  If I login on multiple terminals, I normally want to mount
filesystems in /home/jamie/mnt on one terminal, and use them on another.

> >    - Have a namespace per user.  The user's namespace will be entered
> >      by the "login" program somehow.
> 
> Trivial right now - just have libpam do that.

How can libpam join the user's existing namespace?

Having a separate usermount-namespace for each login of the same user
would not be nice to use.

> >    - All logins to the same user acquire the same per-user namespace.
> >      This isn't possible at the moment; it would be a kernel extension
> >      + administrative change to login.
> 
> No.  Identical setup at login time - sure.  Enforced _single_ namespace
> is just plain wrong.  Moreover, "all user's processes" is the wrong answer
> to practically any question (well, aside of "what processes do you kill
> when you get rid of luser's account").

I agree.  Certainly the kernel should not be looking at uid for this.
The actual determination of which processes share mounts should be
determined entirely by userspace.

But right now, the kernel doesn't provide a mechanism (that I know of)
whereby a new login shell can use the namespace of an existing process
- something that would be desirable if it were possible.

The idea I gave at the start of this mail - a daemon per user spawning
login shells using a shared namespace - would work using the available
CLONE_NEWNS mechanism.  But it doesn't fit very well with libpam, nor
with the usual tree relationship of parent-child processes when using
"su" and such.

-- Jamie

  reply	other threads:[~2005-04-20 12:03 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-19 22:13 [RFC][2.6 patch] Allow creation of new namespaces during mount system call Eric Van Hensbergen
2005-04-19 22:23 ` Al Viro
2005-04-19 23:53   ` Eric Van Hensbergen
2005-04-20  3:33     ` Al Viro
2005-04-20  9:45       ` Jamie Lokier
2005-04-20 10:27         ` Al Viro
2005-04-20 12:03           ` Jamie Lokier [this message]
2005-04-20 12:39             ` Al Viro
2005-04-20 16:51               ` Ram
2005-04-20 17:09                 ` Al Viro
2005-04-20 17:53                   ` Miklos Szeredi
     [not found]                     ` <a4e6962a0504201107518416e9@mail.gmail.com>
2005-04-20 18:18                       ` Eric Van Hensbergen
2005-04-20 18:34                         ` Miklos Szeredi
2005-04-20 20:43                           ` Jamie Lokier
2005-04-20 20:54                             ` Al Viro
2005-04-20 22:16                               ` Jamie Lokier
2005-04-20 21:08                     ` Al Viro
2005-04-20 22:19                       ` Jamie Lokier
2005-04-20 18:00                   ` Eric Van Hensbergen
2005-04-20 18:33                   ` Ram
2005-04-20 22:04                     ` Jamie Lokier
2005-04-30  8:56                       ` Christoph Hellwig
2005-04-30 15:01                         ` Jamie Lokier
2005-05-11  9:05                           ` Christoph Hellwig
2005-04-21  7:33                   ` Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call) Jan Hudec
2005-04-21  8:09                     ` Christoph Hellwig
2005-04-21  9:32                       ` Jan Hudec
2005-04-20 18:57                 ` [RFC][2.6 patch] Allow creation of new namespaces during mount system call Bryan Henderson
2005-04-20 19:37                   ` Miklos Szeredi
2005-04-21  0:08                     ` Bryan Henderson
2005-04-21  8:06                       ` Miklos Szeredi
2005-04-21 13:33                         ` [RFC][patch] mount permissions (was: [RFC][2.6 patch] Allow ...) Miklos Szeredi
2005-04-21 16:57                         ` [RFC][2.6 patch] Allow creation of new namespaces during mount system call Bryan Henderson
2005-04-20 20:51                   ` Al Viro
2005-04-21  0:23                     ` Bryan Henderson
2005-04-21  0:32                       ` Al Viro
2005-04-21  8:10                       ` Christoph Hellwig
2005-04-20 21:09                   ` Ram
2005-04-21  0:42                     ` Bryan Henderson
2005-04-21 19:10                       ` Ram
2005-04-20 18:25               ` Bryan Henderson
2005-04-20 12:48         ` Jan Hudec
2005-04-20 22:13           ` Jamie Lokier
2005-04-21 10:09             ` Jan Hudec
2005-04-21 18:44               ` Jamie Lokier
2005-04-21 18:52                 ` Hiding secrets from root (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call) Jan Hudec
2005-04-21 20:35                   ` Jamie Lokier
2005-04-20 13:14       ` [RFC][2.6 patch] Allow creation of new namespaces during mount system call Eric Van Hensbergen
2005-04-20 13:55         ` Eric Van Hensbergen

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=20050420120340.GC10167@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=ericvh@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).