From: Jan Hudec <bulb@ucw.cz>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: Ram <linuxram@us.ibm.com>, Jamie Lokier <jamie@shareable.org>,
Eric Van Hensbergen <ericvh@gmail.com>,
linux-fsdevel@vger.kernel.org
Subject: Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call)
Date: Thu, 21 Apr 2005 09:33:20 +0200 [thread overview]
Message-ID: <20050421073320.GA335@vagabond> (raw)
In-Reply-To: <20050420170921.GT13052@parcelfarce.linux.theplanet.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]
On Wed, Apr 20, 2005 at 18:09:21 +0100, Al Viro wrote:
> On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
> > Reading through the thread I assume the requirement is:
> >
> > 1) A User being able to create his own VFS-mount environment
> > 2) being able to use the same VFS-mount environment from
> > multiple login sessions.
> > 3) Being able to switch some processes to some other
> > VFS-mount environment.
>
> Excuse me, but could somebody give coherent rationale for such requirements?
> _Especially_ for joining existing group by completely unrelated process -
> something we don't do for any other component of process.
I think I can. And I think I can modify the proposal to something a bit
more sane.
The problem is: The mount should be accessible only by processes started
by the authorized user, but not by other user, including root, who is
capable of changing their uid to the authorized user's id.
The solution can be: The mount is only accessible to the process group
of that user's session. That's easy -- the login process is created
with new namespace.
Now how to allow the user to have that mountpoint accessible from all
sessions? Well, we can already pass open file descriptor to files
inside that mount to unrelated processes along unix domain sockets. So
what is left is being able to mount --bind a directory by it's
filehandle (since it does not have a path in our namespace).
This allows creating a "mount-agent", that would work similar to
ssh-agnet or gpg-agent, but instead of passing secret keys, it would
pass descriptors to that user's mount roots and it's client would bind
them. This agent can do whatever authentication is deemed appropriate
for that mountpoint.
Note however, that it's really hard to protect something against root,
because root can ptrace any process.
Well, being able to mount bind file descriptor might be useful for other
purposes as well and should not be hard to do. Unless you or somebody
finds a security problem with it, but I don't see any. Process having
a directory handle can chdir there anyway, so this does not add it extra
access.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-04-21 7:54 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
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 ` Jan Hudec [this message]
2005-04-21 8:09 ` Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call) 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=20050421073320.GA335@vagabond \
--to=bulb@ucw.cz \
--cc=ericvh@gmail.com \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linuxram@us.ibm.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;
as well as URLs for NNTP newsgroup(s).