public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: serue@us.ibm.com, akpm@linux-foundation.org,
	linux-fsdevel@vger.kernel.org, containers@lists.osdl.org,
	util-linux-ng@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/8] unprivileged mount syscall
Date: Mon, 16 Apr 2007 00:59:06 -0700	[thread overview]
Message-ID: <1176710347.2954.8.camel@ram.us.ibm.com> (raw)
In-Reply-To: <E1HcKQd-0001yO-00@dorka.pomaz.szeredi.hu>

On Fri, 2007-04-13 at 13:58 +0200, Miklos Szeredi wrote:
> > On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > > 1. clone the master namespace.
> > > > 
> > > > 2. in the new namespace
> > > > 
> > > > 	move the tree under /share/$me to /
> > > >         for each ($user, $what, $how) {
> > > >             move /share/$user/$what to /$what
> > > > 	    if ($how == slave) {
> > > >                  make the mount tree under /$what as slave
> > > >             }
> > > >         }
> > > >         
> > > > 3. in the new namespace make the tree under 
> > > >        /share as private and unmount /share
> > > 
> > > Thanks.  I get the basic idea now: the namespace itself need not be
> > > shared between the sessions, it is enough if "share" propagation is
> > > set up between the different namespaces of a user.
> > > 
> > > I don't yet see either in your or Viro's description how the trees
> > > under /share/$USER are initialized.  I guess they are recursively
> > > bound from /, and are made slaves.
> > 
> > yes. I suppose, when a userid is created one of the steps would be
> > 
> > mount --rbind / /share/$USER
> > mount --make-rslave /share/$USER
> > mount --make-rshared /share/$USER
> 
> Thinking a bit more about this, I'm quite sure most users wouldn't
> even want private namespaces.  It would be enough to
> 
>   chroot /share/$USER
> 
> and be done with it.
> 
> Private namespaces are only good for keeping a bunch of mounts
> referenced by a group of processes.  But my guess is, that the natural
> behavior for users is to see a persistent set of mounts.
> 
> If for example they mount something on a remote machine, then log out
> from the ssh session and later log back in, they would want to see
> their previous mount still there.

They will continue see their previous mount tree. 
Even if all the namespaces belonging to the different sessions of the
user get dismantled when all the sessions exit, the a mirror of those 
mount trees continue to exist under /share/$USER in the original
namespace.  So I don't think we have a issue.

NOTE: when I say 'original namespace' I mean the admin namespace; the
first namespace that gets created when the machine boots.

RP


> 
> Miklos


      parent reply	other threads:[~2007-04-16  8:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070404183012.429274832@szeredi.hu>
2007-04-06 23:02 ` [patch 0/8] unprivileged mount syscall Andrew Morton
2007-04-06 23:16   ` H. Peter Anvin
2007-04-06 23:55     ` Jan Engelhardt
2007-04-07  0:22       ` H. Peter Anvin
2007-04-07  3:40         ` Eric Van Hensbergen
2007-04-07  6:48           ` Miklos Szeredi
2007-04-10  8:52     ` Ian Kent
2007-04-11 10:48       ` Miklos Szeredi
2007-04-11 13:48         ` Ian Kent
2007-04-11 14:26           ` Serge E. Hallyn
2007-04-11 14:27             ` Ian Kent
2007-04-11 14:45               ` Serge E. Hallyn
2007-04-07  6:41   ` Miklos Szeredi
2007-04-09 14:38     ` Serge E. Hallyn
2007-04-09 16:24       ` Miklos Szeredi
2007-04-09 17:07         ` Serge E. Hallyn
2007-04-09 17:46           ` Ram Pai
2007-04-09 18:25             ` H. Peter Anvin
2007-04-10 10:33             ` Karel Zak
2007-04-09 20:10           ` Miklos Szeredi
2007-04-10  8:38             ` Ram Pai
2007-04-11 10:44               ` Miklos Szeredi
2007-04-11 18:28                 ` Ram Pai
2007-04-13 11:58                   ` Miklos Szeredi
2007-04-13 13:28                     ` Serge E. Hallyn
2007-04-13 14:05                       ` Miklos Szeredi
2007-04-13 21:44                         ` Serge E. Hallyn
2007-04-15 20:39                           ` Miklos Szeredi
2007-04-16  1:11                             ` Serge E. Hallyn
2007-04-16  8:18                         ` Ram Pai
2007-04-16  9:27                           ` Miklos Szeredi
2007-04-16 15:40                             ` Eric W. Biederman
2007-04-16 15:55                               ` Miklos Szeredi
2007-04-13 20:07                     ` Karel Zak
2007-04-15 20:21                       ` Miklos Szeredi
2007-04-16  7:59                     ` Ram Pai [this message]

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=1176710347.2954.8.camel@ram.us.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=serue@us.ibm.com \
    --cc=util-linux-ng@vger.kernel.org \
    /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