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

[Eric W. Biederman]

Kyle Moffett <mrmacman_g4@xxxxxxx> writes:

> On Jul 14, 2006, at 10:17:28, Serge E. Hallyn wrote:
>> Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx):
>>> 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.
>>> Assuming the uids on a filesystem are  the same set of uids your process is
>>> using is just wrong.
>>
>> But, when I insert a usb keychain disk into my laptop, that fs  assumes the
>> uids on it's fs are the same as uids on my laptop...
>>
>> Solving that problem is interesting, but may be something to work with a much
>> wider community on.  I.e. the cifs and nifs folks.  I haven't even googled to
>> see what they say about it.
>
> IMHO filesystems _and_ processes should be primary objects in a UID  namespace.
> This would make it possible to solve the usb-key problems  _and_ the
> user-mounted FUSE problems.  If "ns0" is the boot uid  namespace, then put the
> freshly mounted USB key in a new "ns1" (names  just for convenience).  All the
> user processes would continue to be  in ns0, but with the kernel keyring system
> you could create a new "uid" keytype and give the logged in user (ns0,user_uid)
> a user-key  with (ns1,0*).  If you added bits to the user-keys to represent the
> equivalent of CAP_DAC_OVERRIDE/CAP_CHOWN/etc for that process and UID
> namespace, then the user could do anything to any file on their USB  key, even
> change ownership, without disrupting the rest of the  system.  Likewise, if you
> did that for user FUSE filesystems, then suid binaries would not be able to get
> themselves into trouble in  exploitive FUSE infinitely-recursive monstrosities.

Thank you!

It is nice to see when someone else gets the point :)

I had not quite considered how that affects user mounted filesystems
but that does look like a real solution.

Now we just need to implement these things and work out the details of
user keys to map user ids.

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/