Re: FUSE merging? (2)

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

 



> 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
namespaces.

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?

Miklos
-
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]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux