From: Ram <linuxram@us.ibm.com>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
Jamie Lokier <jamie@shareable.org>,
linux-fsdevel@vger.kernel.org,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call
Date: Thu, 21 Apr 2005 12:10:54 -0700 [thread overview]
Message-ID: <1114110654.3856.14.camel@localhost> (raw)
In-Reply-To: <OF41FCE7B2.00EA9823-ON88256FEA.000214A0-88256FEA.0003D3FB@us.ibm.com>
On Wed, 2005-04-20 at 17:42, Bryan Henderson wrote:
> >Well I am not aware of issues that can arise if a user is allowed to
> >change to some namespace for which it has permission to switch.
>
> I think I misunderstood your proposal.
>
> >A user 'ram' creates a namespace 'n1' with a device node /dev/n1 having
> >permission 700 owned by the user 'ram'. The user than tailors his
> >namespace with a bunch of mount/umount/binds etc to meet his
> >requirement.
>
> How does that address the setuid problem -- that a setuid program is
> installed with the expectation that when it runs, certain names will
> identify certain files (e.g. /etc/shadow)? But also that certain other
> names will identify a file of the invoker's choosing?
the new namespace 'n1' though created by the user 'ram', carries the
same restrictions to 'ram' . So 'ram' will not be able to mount
something else on /bin or /sbin or anyother directory that it does not
own, even though its done in its own namespace. Hence I dont see how a
attacker would be able fool a malicious setuid program into a genuine
setuid program. hope this is the concern you were talking about. right?
RP
>
> >Trying to understand your proposal to see how it could be used to solve
> >the problem faced by the FUSE project. Are you trying to use a single
> >namespace with invisible mounts capability?
>
> Essentially. It's a compromise. A user can customize his namespace, but
> only within limits that preserve the integrity of the system.
>
> Technically, we have to admit it's not one namespace today or with
> invisible mounts. Because of the way mounts cover up mountpoints, it's
> technically possible for two processes to see different files as the same
> name, if one opened the directory before a mount and the other after.
> "Mounting over" is a curse.
>
> --
> Bryan Henderson IBM Almaden Research Center
> San Jose CA Filesystems
next prev parent reply other threads:[~2005-04-21 19:09 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 ` 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 [this message]
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=1114110654.3856.14.camel@localhost \
--to=linuxram@us.ibm.com \
--cc=ericvh@gmail.com \
--cc=hbryan@us.ibm.com \
--cc=jamie@shareable.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.