svn commit: r347217 - in projects/fuse2: sys/fs/fuse tests/sys/fs/fusefs

[Alan Somers]

On Tue, May 7, 2019 at 11:28 AM Rodney W. Grimes
<freebsd at gndrsh.dnsmgr.net> wrote:
>
> > On Tue, May 7, 2019 at 8:18 AM Bruce Evans <brde at optusnet.com.au> wrote:
> > >
> > > On Tue, 7 May 2019, Alan Somers wrote:
> > >
> > > > Log:
> > > >  fusefs: allow the null chown and null chgrp
> > > >
> > > >  Even an unprivileged user should be able to chown a file to its current
> > > >  owner, or chgrp it to its current group.  Those are no-ops.
> > >
> > > ffs allows this too, but POSIX seems to require appropriate privilege
> > > even for null changes.  Its DESCRIPTION section says "Changing the
> > > user ID is restricted to processes with appropriate privileges."  It
> > > doesn't formally define "Changing", so this can be read as not
> > > restricting null changes.  However, its ERRORS section says that chown()
> > > shall fail with errno [EPERM] if the euid doesn't match the owner of
> > > the file or the calling process doesn't have appropriate privilege
> > > (note: nothing about the null change where only the new and old owners
> > > of the file match).
> >
> > Yeah, I was trying to satisfy pjdfstest, which expects the behavior of
> > UFS.  Do you think we should disallow the null change?  If so we
> > should do it for all file systems, not just fusefs.
>
> That was my first reaction when I read the commit,
> this seems to complicate the code just to satisfy a test,
> and that is usually not a tangible improvment.

pjdfstest is the closest thing there is to an executable version of
the POSIX standards.  It also serves as a description of UFS's and
ZFS's behavior.  I think fusefs should match those two as much as
possible.
-Alan

>
>
> > > Most other attribute-setting syscalls don't allow null changes without
> > > appropriate privilege.  E.g., in ffs:
> > > - chflags() requires VADMIN privilege
> > > - truncate() requires write privilege (this seems to be only checked for
> > >    at the vfs level, where the nullness of a truncation is not easy to
> > >    determine)
> > > - utimes() and friends require VDMIN privilege or write privilege to set
> > >    the current time (with the same layering as for truncate(), so is hard
> > >    to change)
> >
> > But utimensat allows the null change without privileges, because it
> > has an explicit way to specify the null change: UTIME_OMIT.
> >
> > > - chmod() requires VDMIN privilege according to the comment, but VWRITE_ACL
> > >    privilege according to the code.
> > >
> > > Ownership and other attributes are also hard to handle for file systems
> > > that don't support them.  I only care about this for msdosfs.  msdosfs
> > > has fake file ids, but can have only 1 uid per file amd this often doesn't
> > > match the euid, and even root can't change it.  File ids are also used
> > > for VADMIN checks, so tend to cause failures to set even unimportant
> > > attributes like file times when the setting is possible.  But some
> > > impossible settings are silently ignored or silently adjusted to possible
> > > settings.  E.g., for file times, most successful settings lose precision.
> > >
> > > Ownership and other attributes are even harder to handle for file systems
> > > that have more of them than vfs supports.  Even for msdosfs, many attributes
> > > were not reflected in file flags until a few years ago, and file times for
> > > directories are still broken (by reading and writing the times to the wrong
> > > alias -- the "." entry -- in msdosfs.  Only msdosfs finds times there, and
> > > msdosfs doesn't find times from the correct alias).  ACLs are too complicated
> > > for me, even without the problem of translating them.
> > >
> > > fuse has the larger problem of having to implement identical mishandling
> > > of attributes for all file systems that it supports.
> > >
> > > Bruce
> >
> >
>
> --
> Rod Grimes                                                 rgrimes at freebsd.org