LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: serue@us.ibm.com
Cc: miklos@szeredi.hu, serge@hallyn.com, hpa@zytor.com,
linuxram@us.ibm.com, linux-kernel@vger.kernel.org,
containers@lists.osdl.org, linux-security-module@vger.kernel.org,
ebiederm@xmission.com, viro@ftp.linux.org.uk,
linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [patch] unprivileged mounts update
Date: Thu, 26 Apr 2007 21:56:26 +0200 [thread overview]
Message-ID: <E1HhA4o-0002yi-00@dorka.pomaz.szeredi.hu> (raw)
In-Reply-To: <20070426194225.GA11038@sergelap.austin.ibm.com> (serue@us.ibm.com)
> Quoting Miklos Szeredi (miklos@szeredi.hu):
> > > So then as far as you're concerned, the patches which were in -mm will
> > > remain unchanged?
> >
> > Basically yes. I've merged the update patch, which was not yet added
> > to -mm, did some cosmetic code changes, and updated the patch headers.
> >
> > There's one open point, that I think we haven't really explored, and
> > that is the propagation semantics. I think you had the idea, that a
> > propagated mount should inherit ownership from the parent into which
> > it was propagated.
>
> Don't think that was me. I stayed out of those early discussions
> because I wasn't comfortable guessing at the proper semantics yet.
Yes, sorry, it was Eric's suggestion.
> But really, I, as admin, have to set up both propagation and user mounts
> for a particular subtree, so why would I *not* want user mounts to be
> propagated?
>
> So, in my own situation, I have done
>
> make / rshared
> mount --bind /share /share
> make /share unbindable
> for u in $users; do
> mount --rbind / /share/$u/root
> make /share/$u/root rslave
> make /share/$u/root rshared
> mount --bind -o user=$u /share/$u/root/home/$u /share/$u/root/home/$u
> done
>
> All users get chrooted into /share/$USER/root, some also get their own
> namespace. Clearly if a user in a new namespace does
>
> mount --bind -o user=me ~/somedir ~/otherdir
>
> then logs out, and logs back in, I want the ~/otherdir in the new
> namespace (and the one in the 'init' namespace) to also be owned by
> 'me'.
>
> > That sounds good if everyone agrees?
>
> I've shown where I think propagating the mount owner is useful. Can you
> detail a scenario where doing so would be bad? Then we can work toward
> semantics that make sense...
But in your example, the "propagated mount inherits ownership from
parent mount" would also work, since in all namespaces the owner of
the parent would necessary be "me".
The "inherits parent" semantics would work better for example in the
"all nosuid" namespace, where the user is free to modify it's mount
namespace.
If for example propagation is set up from the initial namespace to
this user's namespace and a new mount is added to the initial
namespace, it would be nice if the propagated new mount would also be
owned by the user (and be "nosuid" of course).
Does the above make sense? I'm not sure I've explained clearly
enough.
Miklos
next prev parent reply other threads:[~2007-04-26 19:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 7:45 Miklos Szeredi
2007-04-25 15:18 ` Miklos Szeredi
2007-04-25 16:55 ` H. Peter Anvin
2007-04-25 17:20 ` Serge E. Hallyn
2007-04-25 17:46 ` Eric W. Biederman
2007-04-25 17:56 ` Serge E. Hallyn
2007-04-25 18:41 ` Eric W. Biederman
2007-04-25 18:52 ` Serge E. Hallyn
2007-04-25 19:33 ` Miklos Szeredi
2007-04-26 14:57 ` Serge E. Hallyn
2007-04-26 15:23 ` Miklos Szeredi
2007-04-26 16:19 ` Serge E. Hallyn
2007-04-26 16:29 ` Miklos Szeredi
2007-04-26 19:42 ` Serge E. Hallyn
2007-04-26 19:56 ` Miklos Szeredi [this message]
2007-04-27 2:10 ` Serge E. Hallyn
2007-04-25 17:21 ` Eric W. Biederman
2007-04-25 17:30 ` Serge E. Hallyn
2007-04-26 19:10 ` Jan Engelhardt
2007-04-26 20:27 ` Miklos Szeredi
2007-04-27 4:10 ` Eric W. Biederman
2007-04-27 7:01 ` Jan Engelhardt
2007-04-25 19:33 ` Andrew Morton
2007-04-25 19:45 ` Miklos Szeredi
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=E1HhA4o-0002yi-00@dorka.pomaz.szeredi.hu \
--to=miklos@szeredi.hu \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=serge@hallyn.com \
--cc=serue@us.ibm.com \
--cc=viro@ftp.linux.org.uk \
--subject='Re: [patch] unprivileged mounts update' \
/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
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).