[lkml]   [2005]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: FUSE merging? (2)
> 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".

> IMHO The best thing FUSE could do is to make the mount totally
> invisible: don't return EACCES, don't follow the FUSE mount but stay
> on the original tree. I think it's either this or returning EACCES
> plus the leaf node constraint at mount time.

The leaf node constranint doesn't make sense. The hidden mount thing
does, but it has been very flatly rejected by Al Viro.

There's a nice solution to this (discussed at length earlier): private

I think we are still confusing these two issues, which are in fact

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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-04 11:02    [W:0.383 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site