Date: Wed, 19 Jun 2002 09:50:02 -0700 (PDT) From: Soren Spies <sspies@apple.com> To: freebsd-gnats-submit@FreeBSD.org Subject: docs/39530: access(2) man page has unnecessarily broad warning Message-ID: <200206191650.g5JGo274005669@www.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 39530 >Category: docs >Synopsis: access(2) man page has unnecessarily broad warning >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Jun 19 10:00:01 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Soren Spies >Release: FreeBSD-4.5 >Organization: Apple Computer, Inc >Environment: bash-2.05$ uname -a FreeBSD freebsd.apple.com 4.5-STABLE FreeBSD 4.5-STABLE #1: Mon Apr 22 17:41:12 PDT 2002 jkh@freebsd.apple.com:/usr/obj/usr/local/src/sys/FREEBSD i386 >Description: The access(2) man page has a warning about how "access(2) is a security hole and should never be used." It shouldn't be used to achieve its design goal: allowing a privileged process to know whether its caller has rights on a particular file, but that doesn't mean it should _never_ be used. In a non-privileged situation where you are just curious if something exists (and for some reason don't want to let the failure of a normal system call let you know it has gone missing, or doesn't have write permission any more, etc), access(2) is a perfectly reasonable mechanism ... especially if you don't want to decipher the bits in stat(2) to try and guess whether or not future syscalls to read/write will fail. Given the existence of access(1), it seems FreeBSD itself is using access(2) for something ... programmers might like to do the same and shouldn't be frightened away by the CAVEAT section. There is also some discussion online (eg. http://www.geocrawler.com/archives/3/91/1994/10/50/177659/) about how access(2) is really only a problem for SUID applications. >How-To-Repeat: man 2 access see CAVEAT section be frightened away from an otherwise useful syscall that would help program writers display access hints about a directory on filesystems where it's hard to decipher the bits yourself. This is particularly useful for GUIs (and came up when trying to convince the Mac OS X Finder use access(2) to be usable with AFS volumes). >Fix: The warning could perhaps read "programs should never make access decisions based upon access(2) nor should setUID programs rely on access() in any way." >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206191650.g5JGo274005669>