Re: FUSE merging? (2)
From: Frank van Maarseveen (frankvm_at_frankvm.com)
Date: Sun, 3 Jul 2005 21:36:19 +0200 To: Miklos Szeredi <email@example.com>
On Sun, Jul 03, 2005 at 05:47:58PM +0200, Miklos Szeredi wrote:
> > > > But that's not really acceptable (see previous audit case) unless FUSE
> > > > refuses to mount on non-leaf dirs.
> > >
> > > I don't think the audit case is important. It's easy to work around
> > > it manually by the sysadmin, and for the automatic case it doesn't
> > > really matter (as detailed above).
> > Note that the audit case "as user" is less important than the root case. I
> > consider the latter very important and EACCES will break it when FUSE
> > permits mounting on non-leaf dirs.
> OK. Can you tell me, why you consider it important? And what's your
> proposal for dealing with it?
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. The simple "find -xdev"
by root should just not be affected unless there is a very good reason
(SELinux or other "hardened" solutions).
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 name-space variancy introduced by the first option is only minor:
Mounting anything over a tree which is still in use by a process is
much worse because it tends to be disruptive. And that has always been
[And I would use the kill() equivalence instead of ptrace() because it
is more appropriate. Doing so avoids the risk of accidentally breaking
useful setuid programs - I don't know if that will happen but I don't
see any security issues here.]
-- Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/