Date: Tue, 31 Jul 2001 12:25:39 -0400 From: Mike Barcroft <mike@FreeBSD.ORG> To: Yar Tikhiy <yar@FreeBSD.ORG> Cc: audit@FreeBSD.ORG Subject: Re: finger(1) & fingerd(8) Message-ID: <20010731122539.A93248@coffee.q9media.com> In-Reply-To: <20010731144344.B30628@comp.chem.msu.su>; from yar@FreeBSD.ORG on Tue, Jul 31, 2001 at 02:43:45PM %2B0400 References: <20010728155159.A35483@snark.rinet.ru> <20010728144554.C86837@coffee.q9media.com> <20010730212257.C26476@comp.chem.msu.su> <20010730144542.A92125@coffee.q9media.com> <20010731144344.B30628@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 31, 2001 at 02:43:45PM +0400, Yar Tikhiy wrote: > On Mon, Jul 30, 2001 at 02:45:42PM -0400, Mike Barcroft wrote: > > CAVEAT > > Access() is a potential security hole and should never be used. > > IMHO this caveat is akin to a memorable quote from an article on > the Daemon News: "One of the differences between FreeBSD and NetBSD > is that the former needs quoting parameter values in rc.conf, and > the latter need not". I mean they both push people along the easiest, > but thoughtless route. > > The actual problem about access(2) is not in programmer's unawareness > of races, but in the syscall's design itself. It was intended to > be a way to check a file against real user credentials instead of > effective ones. And it turned out a Really Bad Way of doing that. > > Ugh, what I did was convinced myself that access(2) shouldn't be > used, but the argument was not security, but the risk of getting > access(2) obsolete one day, as it already happened to creat(2) :-) If a programmer uses access(2) without full knowledge of how it works, the fact that it uses the real user ID instead of the effective user ID can also be a big problem. But this reflects a more general concern with secure programming and isn't specific to this API. > > > Second, open(2) can't be used as a drop-in replacement for access(.., > > > F_OK) here because it can't tell permission errors on a directory from > > > those on a file itself. IMHO stat(2) should be used here if the > > > historical behaviour of finger(1) is to be preserved. > > > > I'm afraid I don't understand what you mean. How does > > access(buf, F_OK) differ from open(buf, O_RDONLY) in terms of > > permissions in this case? From the access(2) man page: > > > > All components of the pathname path are checked for access > > permissions (including F_OK). > > Don't believe newspapers and manpages blindly ;-) Access(..., F_OK) > returns 0 if a file can be seen, but can't be read. One should be able to trust man pages. If the manual isn't factually correct, that's a bug. In this case the manual is incorrect. I now agree that stat(2) is the correct replacement interface. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010731122539.A93248>