access(2) (was: Writing to A NON-Existing File in "C")

[Stephen J. Friedl]

In article <887 at cresswell.quintus.UUCP>, ok at quintus.UUCP (Richard A. O'Keefe) writes:
> In article <14020030 at hpisod2.HP.COM>, decot at hpisod2.HP.COM (Dave Decot) writes:
> > access(2) should not be used to determine the other access permissions
> > except in setuid programs, and even then, not for testing execute
> > access by setuid-root programs.
> 
> where is the harm in subsequently using access(2) to test for permission to
> read or write a file?
> 
> Is there any legitimate reason why someone might take a program which was
> not originally designed to run setuid or setguid and do chmod u+s
> or chmod g+s to it?

[let's call this never-to-run-setuid program "foo"]

     Probably not in the manner you suggest, but making "foo" part
of a larger, setuid/setgid system should be entirely legitimate.
The front-end program to a financial system at a customer is
called "acctmenu", and it runs set-group-id to the accounting
group.  No human is a member of that group, and the /usr/acct
directory is generally unavailable to all by the accounting
system.  Acctmenu calls up menus, reports, forms, and *scripts*,
all as the accounting group.

     If "foo" is called by this script and it uses access(2) just
to see if a file is around, it will break almost every time.  We see
this all the time with the Sys V shell, the Informix database,
mkdir(1), and other programs that either use access(2) in a lazy
manner or don't do it entirely correctly.

     Please, if you don't fully understand the difficulties
we claim then you probably don't understand access(2) enough
to be using it correctly.  Send mail with questions if you want
to learn the right way, but please don't use it.  Trust us.

-- 
Steve Friedl       V-Systems, Inc.      Resident access(2) basher
friedl at vsi.com   {backbones}!vsi.com!friedl    attmail!vsi!friedl