Date: Thu, 14 Dec 2006 02:31:52 +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: <20061214011927.X994@besplex.bde.org> In-Reply-To: <200612131146.kBDBkdQv050907@repoman.freebsd.org> References: <200612131146.kBDBkdQv050907@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Also, non-null changes within the group don't require super-user permissions. 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. All this is mainly for ffs. Many file systems are probably still stricter. Some non-POSIX ones should be less strict when they only have fake attributes and the fake attributes get in the way of making null changes. Sorry I didn't update the man page or all file systems for this. A previous change to chown.2 copied bad grammar (a comma splice) from somwhere. Grep for "more info" in *.2 to see some good and bad examples. intro.2 uses a semicolon splice, but using a new sentence seems to be most common. The wording in examples with correct grammar also tends to be more formal (a bit too formal/verbose for me). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061214011927.X994>