Messages in this thread | | | Date | Sun, 3 Jul 2005 21:36:19 +0200 | From | Frank van Maarseveen <> | Subject | Re: FUSE merging? (2) |
| |
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 possible.
[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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |