Re: [PATCH -mm 5/7] add user namespace

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> If you permission checks are not (user namespace, uid) what can't you do?
> >
> > File descripters can only be passed over a unix socket, right?
> 
> No.  You can use /proc to do the same thing.  You can inherit

How?

> file descriptors, etc.  This isn't a door you can just close and ignore.
> It is too easy to do this to assume you have closed every possible
> way to get a descriptor from outside of ``container''.
> 
> Suppose you have user fred uid 1000 outside of any containers,
> and you have user joe uid 1000 inside user uid namespace.  If you don't
> make your permission checks (user namespace, uid) fred can do terrible

Only if user fred can reach user joe's files.

> If I we don't do the expanded permission checks the only alternative
> is to check to see if every object is in our ``container'' at every
> access.  That isn't something I want to do.

Ditto.

> I don't intend to partition objects just partition object look ups by name.
> Which means that if you very carefully setup your initial process you
> will never be able to find an object outside of your namespace.  But
> the kernel never should assume user space has done that.

Are you contradicting yourself here?

> > So this seems to fall into the same "userspace should set things up
> > sanely" argument you've brought up before.
> 
> For using it yes.  But not for correct kernel operation.

Well if we say the kernel controls files (barring LSMs) based on simple
uids, then that is correct kernel operation :)

In other words we're not letting the kernel do anything it isn't
supposed to do.

> > Don't get me wrong though - the idea of using in-kernel keys as
> > cross-namespace uid's is definately interesting.
> 
> That is their role in the kernel.

They have more roles than that...

I phrased it the way I did to point out we shouldn't need to be using
ecryptfs - which uses the keyring to store actual encryptions keys - to
do this.

> A flavor of key to handle uid
> mapping needs to be added, but that is all.

How can that be all?  How do we represent this on the filesystem then?

We can't store (namespace, uid) because we presumably dont' have actual
external unique ids for a namespace.  So we really will need to provide
global uids, and store those in the keys (and with the files).  So now
3475276bc0dcd9cc501ba9bb7f12683f1b867066 is my uid no matter where I am,
for instance.

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/