Path: utzoo!mnetor!uunet!husc6!think!ames!hc!beta!unm-la!unmvax!turing.UNM.EDU!mike
From: mike@turing.UNM.EDU (Michael I. Bushnell)
Newsgroups: comp.unix.wizards
Subject: Re: Writing to A NON-Existing File in "C"
Message-ID: <973@unmvax.unm.edu>
Date: 20 Apr 88 03:08:18 GMT
References: <9654@jplgodo.UUCP> <14020030@hpisod2.HP.COM>
Sender: news@unmvax.unm.edu
Reply-To: mike@turing.UNM.EDU.UUCP (Michael I. Bushnell)
Organization: University of New Mexico, Albuquerque
Lines: 55

In article <14020030@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes:

>> 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.

>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).

>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):

Make access call
  if FAILED
     report error, die;
Do funky stuff (requiring root permissions)
setuid(geteuid)
exec(USER PROGRAM)

Yes, I know, there are problems if the user deletes or otherwise
messes with things on the program, but there are ways around that.






                N u m q u a m   G l o r i a   D e o 

			Michael I. Bushnell
			HASA - "A" division
14308 Skyline Rd NE				Computer Science Dept.
Albuquerque, NM  87123		OR		Farris Engineering Ctr.
	OR					University of New Mexico
mike@turing.unm.edu				Albuquerque, NM  87131
{ucbvax,gatech}!unmvax!turing.unm.edu!mike