Date: Tue, 8 Jul 2008 14:50:07 GMT From: clemens fischer <ino-news@spotteswoode.dnsalias.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/125009: access(2) grants root execute perms for non-executable files Message-ID: <200807081450.m68Eo7ub063014@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/125009; it has been noted by GNATS. From: clemens fischer <ino-news@spotteswoode.dnsalias.org> To: Jaakko Heinonen <jh@saunalahti.fi> Cc: bug-followup@FreeBSD.org Subject: Re: kern/125009: access(2) grants root execute perms for non-executable files Date: Tue, 8 Jul 2008 16:17:47 +0200 > Jaakko Heinonen: > On 2008-06-26, clemens fischer wrote: > > this check works correctly for non-root, but any file accessible in > > any way for root _passes_ the "(access(argv[0], X_OK) < 0)" check, > > a subsequent execvp(3) fails. doing "git-init; date > fileA; > > git-commit -a" as a non-privileged user works as expected. > > At first sight it may look like that it's not a bug. From FreeBSD > access(2) manual page: > > Even if a process's real or effective user has appropriate > privileges and indicates success for X_OK, the file may not > actually have execute per- mission bits set. Likewise for R_OK > and W_OK. ok, i read this passage, and the "bug" is documented behaviour, but it doesn't make sense in real life. hence the way git(1) fails. Linux returning EACCES follows the principle of least astinishment. it saves programmers writing extra code when all he wanted to express has already been tested. > However it boils down to how one defines "appropriate privileges". > execve(2) has a special check for root: a file must have at least one > execute bit set, otherwise execve(2) returns EACCES even for root. > Thus I think that it's reasonable to say that there aren't > "appropriate privileges" for root unless at least one execute bit is > set for a (regular) file. oh, yes! > [text of patches removed, they look correct to me] > I also tested how some other operating systems behave: > > (access(2) X_OK call as root for a regular file which has no execute > bits set) > > Mac OS X 10.4 returns EPERM (for users it returns EACCES and strangely > it returns 0 (OK) for device files) > > Linux (recent Ubuntu kernel) returns EACCES > > NetBSD returns EACCES > > OpenBSD 4.3 returns 0 (same as FreeBSD) i really appreciate your looking into this so thoroughly! > > but this isn't a git-problem anyway: i took > > /usr/src/tools/regression/security/access/* and changed every check for > > "access(path, R_OK)" into "access(path, X_OK)". as the test files in > > this test are created modes 0400 and 0040, one would expect every check > > to fail when using X_OK, but the output is: > > > > : /src/localcode/test/access > > : 0 # ./testaccess > > : Effective uid was used instead of real uid in access(). > > : Effective gid was used instead of real gid in access(). > > : 2 errors seen. > > I don't think that your change to the test and these errors are relevant > to the actual problem. I didn't check thoroughly though. well, if access(2) had made sure any execute bits were set, _all_ the tests had failed. i hope your fix is committed. regards, clemens
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807081450.m68Eo7ub063014>