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

[Eric W. Biederman]

Cedric Le Goater <clg@xxxxxxxxxx> writes:

> Eric W. Biederman wrote:
>
>>> I think user namespace should be unshared with filesystem. if not, the
>>> user/admin should know what is doing.
>> 
>> No.  The uids in a filesystem are interpreted in some user namespace
>> context.  We can discover that context at the first mount of the
>> filesystem. 
>
> ok. so once you're in such a user namespace, you can't unshare from it
> without loosing access to all your files ?

Any file that is accessible without needing specific user and group
permissions will still be accessible.  In essence you are an enhanced
version of the nobody user when you access files outside of your
namespace.  What you can't do is create files as you cannot be
represented on the filesystem.

>> Assuming the uids on a filesystem are the same set of uids your process
>> is using is just wrong.
>
> well, this is what is currently done without user namespaces.

Yes.  But the whole system is assumed to be in the same user namespace,
so that is a reasonable assumption.  Once we break that assumption we
need to do something different.  There are a few network filesystems
that are at least working on using keys to authenticate users.

>>>> I believe some of the key infrastructure which is roughly kerberos
>>>> authentication tokens could be used for this purpose.
>>> please elaborate ? i'm not sure to understand why you want to use the keys
>>> to map users.
>> 
>> keys are essentially security credentials for something besides the
>> local kernel.  Think kerberos tickets.  That makes the keys the
>> obvious place to say what uid you are in a different user namespace
>> and similar things.
>
> what about performance ? wouldn't that slow the checking ?

It needs to be looked at, but it shouldn't slow the same namespace
case, and permission checking is largely a slow path issue.  So a little
overhead at open time is preferred to overhead after you get the file
open.

Mapping users is clearly a separate problem, but related problem.  For
sharing read-only data that you don't mind sharing with everyone the
current set of semantics I have described is fine.  

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