From owner-freebsd-security Fri Oct 11 1:53:30 2002 Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05BE837B401 for ; Fri, 11 Oct 2002 01:53:28 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7AD943EC5 for ; Fri, 11 Oct 2002 01:53:26 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA11922; Fri, 11 Oct 2002 18:53:11 +1000 Date: Fri, 11 Oct 2002 19:03:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz Cc: Peter Jeremy , The Anarcat , FreeBSD Security Issues Subject: Re: access() is a security hole? In-Reply-To: <20021010193137.GA13547@HAL9000.homeunix.com> Message-ID: <20021011185423.B12227-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 10 Oct 2002, David Schultz wrote: > Thus spake Peter Jeremy : > > On 2002-Oct-08 17:23:35 -0400, The Anarcat wrote: > > >Also, this means that the stat() manpage should also contains a > > >similar section about its non-fd incarnations. > > > > I disagree. access(2) is specifically designed to allow setuid/setgid > > programs to validate access rights based on the real uid/gid - but is > > virtually impossible to use safely for this task because of the > > inherent race conditions. > > No, access(2) is designed to allow NON-setuid programs to easily > do sanity checks without opening a file or device right away. > There's still a race condition, but it isn't typically a security > threat when all you're trying to do is prevent the user from > shooting himself in the foot. To use access() in a setuid program > is usually an error. No, it was designed to be useful to setuid programs. Whether it actually is useful is arguable. From the V7 manual: "The user and group IDs with respect to which permission is checked are the real UID and GID of the process, so that this call is useful to set-UID programs". Setuid programs should only use access() to check whether they will have permission after they set[ug]id() to the real [ug]id. Non-setuid programs mostly don't need such checks. They can just try the operation. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message