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]
