Date: Wed, 8 May 2019 00:18:30 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alan Somers <asomers@freebsd.org> Cc: 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: <20190507231529.I1127@besplex.bde.org> In-Reply-To: <201905070127.x471ROvf000119@repo.freebsd.org> References: <201905070127.x471ROvf000119@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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) - 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?20190507231529.I1127>