kern/125009: access(2) grants root execute perms for non-executable files

[clemens fischer]

The following reply was made to PR kern/125009; it has been noted by GNATS.

From: clemens fischer <ino-news at spotteswoode.dnsalias.org>
To: Jaakko Heinonen <jh at saunalahti.fi>
Cc: bug-followup at 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