lkml.org 
[lkml]   [2005]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-07-03 21:41    [W:0.118 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site