Date: Wed, 8 May 2019 02:11:48 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alan Somers <asomers@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, 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: <20190508015918.X1615@besplex.bde.org> In-Reply-To: <CAOtMX2iazsHTELYRniuNHepWC211nUGA1C=VVo6rcV9bMiS49g@mail.gmail.com> References: <201905070127.x471ROvf000119@repo.freebsd.org> <20190507231529.I1127@besplex.bde.org> <CAOtMX2iazsHTELYRniuNHepWC211nUGA1C=VVo6rcV9bMiS49g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 May 2019, Alan Somers wrote: > 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. No, I think we should go the other way and allow null changes for other syscalls, and maybe get POSIX changed or clarified to allow the ffs behaviour. ISTR changing ffs to do what it does now, but ufs_chown() has allowed null changes without privilege since at least FreeBSD-1, so the only thing I might have changed is from strict POSIX back to the old behaviour. >> 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. I forgot about utimensat(). This is technically best, but complicated. Full complications would have use options to control use of weakened privileges annd weakened error checking. This reminds me that mv(1) was weakened (broken) to not report loss of file flags when moving across mount points. This would be reasonable as a default for cp -pR where the reporting is still done, but not for mv. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190508015918.X1615>