access(2) (was: Writing to A NON-Existing File in "C")
Dave Decot
decot at hpisod2.HP.COM
Thu Apr 21 16:32:07 AEST 1988
> >> AAAAAAAAAARGH! Please do not use access(2) as a handy-dandy
> >> "does the file exist?" function. It is designed to be used
> >> by set-{user,group}-id programs to see if the underlying user
> >> has permission to access the file in the requested manner.
>
> >Uh...I think a file's existence is independent of your user-id.
>
> Nope. A file can be said to "exist" for a process if you can SEARCH
> ALL THE DIRECTORIES in the path leading to the file. So, if you are
> under suid conditions, use access for F_OK, then you will get
> misleading results if a directory along the path wasn't searcheable
> for your real uid.
Sounds to me like a weird definition of "exist", but apparently
most implementations of access(2) agree with you. I just tried
it out, and you're right.
> >It's perfectly acceptable to use access(2) the F_OK (0) value of amode
> >it to determine whether files exist. Such calls succeed exactly when
> >calls to stat(2) succeed.
>
> So, DON'T use access(2) EVER unless you are a suid program (or have
> done setuid(geteuid()) (which is really perverse in non-suid programs).
If the process has chdir()'ed to the directory where it is thinking of
accessing the file, there can be no harm in seeing whether the file
is here or not.
However, given what you've said about the other cases, I'll use stat()
in this case as well.
> >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.
>
> Why not? What if I have a suid program which executes a given user
> program in a funky way, with appropriate permission settings, but it
> needs to determine if it will be able to run the program before is
> does its funky stuff (to wit):
It does not correctly detect whether the superuser can execute
files with mode 0. access() always returns 0 if the ruid is superuser
and the file exists, even if no execute bits are turned on for the file.
Such files cannot actually be executed, even by the superuser.
Dave Decot
hpda!decot
More information about the Comp.unix.wizards
mailing list