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

Kyle Moffett
2006-07-14T15:44:22Z

On Jul 14, 2006, at 10:17:28, Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> 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.

Cheers,
Kyle Moffett