Re: [fuse-devel] Lets stat() at mountpoint return something (for file system boundaries detection)

[Robert S. <Rob...@ba...>]

On Wed, Sep 06, 2006 at 11:07:45AM +0200, Miklos Szeredi wrote:
> > Utilities try to check file system boundaries using stat(). This fails
> > on an untrusted FUSE fs.
> > 
> > Is it possible to force the kernel to return a cooked up stat structure
> > that reveals at least a file system switch instead of returning
> > unexpected results (EACCESS) at the mount point?
> > 
> 
> In theory this could be done.  However I don't see much advantage.
> 
> Do you have a concrete example why this case is problematic?


Of course, I do. (-:

E.g. backup tools like rsync, even if configured to stay on the current
file system report an error, because they have _no_means_ to distinguish
it from something non-serious. How should one programatically handle an
unexpected failure of stat(), if not serious? But the cause - some user
mounted a FUSE fs - is not serious at all.

This is not as contradictory as someone could expect for FUSE.
The contradiction that root cannot (normally) read foreign FUSE fs is
not valid here, as root (or whoever else) doesnt want to read it, he
wants to avoid it!

The best way I see to do it is to mark it clearly as a file system
boundary, revealing this state with stat(mountpoint).
This has two outrageous advantages:

-thousands of existing programs need no adaption
-stat() quits violating it's own policy (as documented it needs no
 permissions to return successfully (apart from "execute" permissions on
 the directories down to the mount point in question, but this not even
 for root))


It is more then annoying to any administrator that users can create
root-un-stat()able files on a root-administered file system. This is
a serious issue and could lead to generall disallowance of FUSE for
users. But user freedom is one thing that FUSE is about, isn't it?



Greetings,
		Robert

PS: There are other examples like "find", and any other fs traversing
tool which has an "-xdev" switch... Additionally, rsync considers itself
probably less a backup, but a synchronizing tool... <-:

PS2: I recommend returning something "all-zeros" like
d--------- 0 root root 0 1970-1-1 mountpoint
if the request can't be passed to the fuse daemon. Or one can possibly
mix in the real values of the underlying mountpoint dir.