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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jul 14, 2006, at 10:17:28, Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([email protected]):
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

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux