Date: Wed, 13 Dec 2006 17:04:44 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> 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: <20061213160444.GE793@garage.freebsd.pl> In-Reply-To: <20061214011927.X994@besplex.bde.org> References: <200612131146.kBDBkdQv050907@repoman.freebsd.org> <20061214011927.X994@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--CXFpZVxO6m2Ol4tQ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2006 at 02:31:52AM +1100, Bruce Evans wrote: > On Wed, 13 Dec 2006, Pawel Jakub Dawidek wrote: >=20 > >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 wi= ll > > return 0. >=20 > 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=3D-1 and gid=3D-1 it works always (I don't have to have VADMIN access). > [...] Also, non-null changes within the group don't require super-user > permissions. Right. > The details for this are hard to describe. They are at least as complicat= ed > 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 =3D=3D old file uid =3D=3D new file uid), so why d= isallow > null changes? The uid checks should be sufficient." McKusick agreed > with this. Do you have a suggestion how we can describe it properly? > 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. I'm going to check this. I'm writting regression tests based on UFS behaviour and want to run them on ZFS when I finish. I'm trying to create protable code, so that we can try it on different operating system and compare the results. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --CXFpZVxO6m2Ol4tQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgCScForvXbEpPzQRAg3xAKDvnvSOveGdejtlWTBMglWyhBAW9ACdFgTQ SD4LBYgZJAdn61fHuDKP9QM= =Kkol -----END PGP SIGNATURE----- --CXFpZVxO6m2Ol4tQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061213160444.GE793>