On Mon, Jul 04, 2005 at 10:56:30AM +0200, Miklos Szeredi wrote: > > It is important because on UNIX, "root" rules on local filesystems. > > I dont't like the idea of root not being able to run "find -xdev" > > anymore for administrative tasks, just because something got hidden > > by accident or just for fun by a user. It's not about malicious > > users who want to hide data: they can do that in tons of ways. > > That's a sort of security by obscurity: if the user is dumb enough he > cannot do any harm. But I'm not interested in that sort of thing. If > this issue important, then it should be solved properly, and not just > by "preventing accidents".
"solving it properly" refers to hardening the leaf node constraint against circumvention I assume. Suppose there's a script for doing simple on-line backups using "find". Now explain to the user why he lost his data due to a backup script geting EACCES on a non-leaf FUSE mount. I don't think that's acceptable. On the other hand, when the user stored something _deliberately_ under a mountpoint, circumventing the leaf node constraint by some trickery then it is clearly his own fault when the data is lost. Anyway, a leaf node constraint can be hardened against misuse later on, should it become necessary. Your bind-mount case to circumvent this restriction is slightly flawed because it requires root interaction. > > There's a nice solution to this (discussed at length earlier): private > namespaces. I thought that's rejected because a process doesn't automatically get the right namespace after rsh into such a machine? And fixing it by adjusting the name-space of a process (by whatever means) is not transparent. > I think we are still confusing these two issues, which are in fact > separate. > > 1) polluting global namespace is bad (find -xdev issue) > > 2) not ptraceable (or not killable) processes should not be able to > access an unprivileged mount > > For 1) private namespaces are the proper solution. For 2) the > fuse_allow_task() in it's current or modified form (to check > killability) should be OK. > > 1) is completely orthogonal to FUSE. 2) is currently provably secure, > and doesn't seem cause problems in practice. Do you have a concrete > example, where it would cause problems? See above backup scenario. Issues (1) and (2) are tied together I'm afraid: When using a private name-space and thus assuming an unrelated process needs to do something very special to get that name-space then (2) would not be needed at all. On the other hand, Name-space inheritance by setuid processes suddenly becomes an issue: issue (2) is re-appearing but at another place. -- Frank - 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/