Date: Thu, 14 Dec 2006 04:32:43 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libc/sys chown.2 Message-ID: <20061214031601.F1578@besplex.bde.org> In-Reply-To: <20061213160444.GE793@garage.freebsd.pl> References: <200612131146.kBDBkdQv050907@repoman.freebsd.org> <20061214011927.X994@besplex.bde.org> <20061213160444.GE793@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Dec 2006, Pawel Jakub Dawidek wrote: > On Thu, Dec 14, 2006 at 02:31:52AM +1100, Bruce Evans wrote: >> On Wed, 13 Dec 2006, Pawel Jakub Dawidek wrote: >> >>> pjd 2006-12-13 11:46:38 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> lib/libc/sys chown.2 >>> Log: >>> Be more precise with EPERM description. When chown(2) is a no-op, it will >>> return 0. >> >> VADMIN access is still required for null changes. This normally means >> that the the caller must own the file, but there are complications for >> ACLs. [...] > > Right, my testing wasn't precise. > > But still, if I pass uid=-1 and gid=-1 it works always (I don't have to > have VADMIN access). I forget about these. They are magic and mean "don't change, and (?) succeed in some permisions checks based on ids". Hmm, their operation is tricky: First, the -1's are excessively magic. They just happen to be identical to VNOVAL when converted to ids. setfown() depends on this when it copies the userland values to vattr. This isn't a problem in practice of course -- VNOVAL is the same magic -1. When both ids are VNOVAL, the VOP_SETATTR() call is already null and doesn't do anything (for ffs, it doesn't even call ufs_chown()). POSIX allows it to either update or not update the ctime, but I think allowing the update is a bug in POSIX -- it lets anyone clobber the ctime of any file, at least with my interpretation of null changes to gids. When at least one id is not VNOVAL, for ffs ufs_chown() is called and it does the VADMIN check after replacing uid == VNOVAL with the file uid. This prevents further problems. In this case, POSIX requires the ctime to be be marked for update even for null changes, and FreeBSD implements this. The VADMIN check prevents anyone clobbering ctime of any file using this type of null change. >> The details for this are hard to describe. They are at least as complicated >> as: >> - the effective uid must be the super-user, unless all of the following: >> . it is the same as the file's uid, or [complications for ACLs] >> . the change to the uids of the file is null >> . [permission is never granted based solely on the egid-- check this] >> . the change to the gids is either null or the new file gid is in the >> same group as the egid. >> . [nothing is required or the old file gid -- check this] >> I used fine print in POSIX to justify permitting null changes to the >> gid. FreeBSD-1 doesn't allow this. My reasoning was something like >> "non-null changes (from a gid not in our group to one in our group) >> are permitted (if euid == old file uid == new file uid), so why disallow >> null changes? The uid checks should be sufficient." McKusick agreed >> with this. > > Do you have a suggestion how we can describe it properly? Write your regression tests for all cases first :-). Check POSIX. I'm too tired to understand the details that POSIX gives now. It gives more details than I remember, and still requires a subtle interpretation of "change" as "non-null change" to permit certain null changes of gids. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061214031601.F1578>