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

[Greg Limes]

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.

> If a program which is never intended to run setuid ensures that it is
> not being run setuid or setgid by [aborting if getuid() != geteuid()]
> 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?

Occasionally I need to do a single command, as a different uid -- bin,
daemon, games, whatever; usually an install, or changing a
configuration file, or whathaveyou. So, I have a little utility that
checks for permission, sets the effective user id, and execs the
requested command. A program as described above would detect that it is
running "setuid", and fail. So, it is not necessary to actually set the
setuid and setgid bits on a program for the real and effective uids to
be different.

I would like to pose a modified version of your question back at you:
Is there any legitimate reason why someone might need to disable
switchuser-ed access to a program? (not a flame, an invitation for
discussion ... I use this little utility quite a lot, and in fact rarely
log in a "root" or start a root shell, even when configuring kernels).

-- Greg Limes [limes at sun.com]			frames to /dev/fb