Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 May 2019 09:03:21 -0600
From:      Alan Somers <asomers@freebsd.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-projects@freebsd.org
Subject:   Re: svn commit: r347217 - in projects/fuse2: sys/fs/fuse tests/sys/fs/fusefs
Message-ID:  <CAOtMX2iazsHTELYRniuNHepWC211nUGA1C=VVo6rcV9bMiS49g@mail.gmail.com>
In-Reply-To: <20190507231529.I1127@besplex.bde.org>
References:  <201905070127.x471ROvf000119@repo.freebsd.org> <20190507231529.I1127@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 7, 2019 at 8:18 AM Bruce Evans <brde@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.

>
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2iazsHTELYRniuNHepWC211nUGA1C=VVo6rcV9bMiS49g>