From owner-freebsd-bugs@FreeBSD.ORG Tue Jul 8 14:50:07 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD3A3106567D for ; Tue, 8 Jul 2008 14:50:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BB2298FC18 for ; Tue, 8 Jul 2008 14:50:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m68Eo7gn063015 for ; Tue, 8 Jul 2008 14:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m68Eo7ub063014; Tue, 8 Jul 2008 14:50:07 GMT (envelope-from gnats) Date: Tue, 8 Jul 2008 14:50:07 GMT Message-Id: <200807081450.m68Eo7ub063014@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: clemens fischer Cc: Subject: Re: kern/125009: access(2) grants root execute perms for non-executable files X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: clemens fischer List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2008 14:50:07 -0000 The following reply was made to PR kern/125009; it has been noted by GNATS. From: clemens fischer To: Jaakko Heinonen 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