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

[ebiederm@xmission.com (Eric W. Biederman)]

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> 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?

/proc/<pid>/fd/...
/proc/<pid>/exe
/proc/<pid>/cwd

It isn't quite the same as you are actually opening a second
copy of the file descriptor but the essence is the same.

>> 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 they are logged in a the same time this is possible.

>> 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.
                                                            ^just
>> 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?

I don't think so.

Basically what I am saying all new looks happen in the new namespace.
That makes it hard to find objects that are not in your namespace.
If you already have those objects open, or if can find a way besides
lookup by name to access those objects you can see objects in another
namespace.

>> > 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 :)

If we so define it yes, I believe that definition is wrong.

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

In the context of user namespaces if the compare is not 
(user_ns, uid) == (other_user_ns, other_uid) then we are.

>> > 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.

Ok. I will buy that.

>> 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?

You handle it at the VFS layer unless the filesystem overrides the
permission checks.

> 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.

That is one way to do it.  Anyway as long as we can see it is possible using
keys now we can sort out the rest of the details later.

Eric

-
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/