Re: FUSE merging?

[Frank van Maarseveen]

On Fri, Jul 01, 2005 at 12:27:01PM +0200, Miklos Szeredi wrote:
> 
> You mean suid programs are never to touch paths passed to them?

never when euid==root.
The pathname could even point into /proc or anything else yet unknown,
e.g. by putting some symlinks at the right places. The mere act of
opening the file as root could have unwanted side effects already.

> 
> If that would be true, then fuse_allow_task() would not be needed, but
> would do no harm either, since it would never be invoked by a suid
> program.

In theory it should not be necessary. But on a practical side: we need
to provide security for daemons with elevated privileges which need to
traverse all local disks.

> You didn't consider the information leak aspect (point B in fuse.txt).

Correct. I have no answer to that other than: is it a real problem or
yet something else a setuid program should take into consideration?
And what info can we extract already using inotify/dnotify? There are
several ways to monitor activity and it is all information. /proc (ps)
gives information too.

> > -	Forbid hiding data by mounting a FUSE filesystem on top of it (does
> > 	FUSE check for this already?)
> 
> Yes.  It checks for writablilty on the mountpoing (excluding limited
> writablilty as /tmp for example).

But can you mount FUSE on top of a populated tree, a non-leaf dir?

> > -	/proc isn't a problem: most root processes tend to avoid it because
> > 	it is synthetic and thus uninteresting. Maybe we should extend
> > 	the idea of "synthetic file-systems being uninteresting" to any
> > 	process which cannot receive signals from the FUSE mount owner. When
> > 	one cannot hide data by a FUSE mount and its synthetic anyway so not
> > 	interesting then just show the original empty mount point.
> 
> Been there.  People (like Al Viro) didn't like it.

including changing the ptraceability test by a signal test and including
the (IMHO) required emptyness of the mount stub?

Traversing a FUSE mountpoint is almost equivalent to talking with a
userspace program. Why should that be interesting when one simply wants
to traverse the FS? root isn't going to execute all user programs to
see what they do either.

-- 
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/