On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote:
> > Could you explain a little more?  I don't see the point in denying
> > access to root, but I also can't tell from your explanation whether you
> > do or not.
> 
> Fuse by default does.  This can be disabled by one of two mount
> options: "allow_other" and "allow_root".  The former implies the
> later.  These mount options are only allowed for mounting by root, but
> this can be relaxed with a configuration option.
> 
> > If I mount a filesystem using ssh, I want to be able to "sudo cp
> > foo.txt /etc" and not get an inexplicable permissions error.
> 
> If you can do that sudo, you can also modify the configuration and use
> one of the mount options.

And that's as false as it can be! Ok, no sane admin would probably give
out sudo permissions for cp, but other commands may make sense (perhaps
setting some sysctl in /proc -- that needs fsuid=0 -- otherwise one
could teach sudo to set euid, but not fsuid). And than the user would
*NOT* be able to use those mount options.

Anyway, why are the options not available to non-root? It's their
filesystem, they should be allowed to set it up!

> > >   4) Access should not be further restricted for the owner of the
> > >      mount, even if permission bits, uid or gid would suggest
> > >      otherwise
> > 
> > Similar questions.
> 
> This behavior can be disabled by the "default_permissions" mount
> option (wich is not privileged, since it adds restrictions).  A FUSE
> filesystem mounted by root (and not for private purposes) would
> normally be done with "allow_other,default_permissions".

I'd hell lot prefer it the other way around. The user write bit is
an accident counter-measure similarly to the root squashing.

It needs to be split to two orthogonal options -- one to specify,
whether all files are owned by the mounter or by whomever the filesystem
says and another whether permissions are checked.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec <[EMAIL 
PROTECTED]>

Attachment: signature.asc
Description: Digital signature

Reply via email to