[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:3.419 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site