Re: FUSE merging?

Frank van Maarseveen
2005-07-01T12:00:40Z

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