Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!limes From: limes@sun.uucp (Greg Limes) Newsgroups: comp.unix.wizards Subject: Re: access(2) (was: Writing to A NON-Existing File in "C") Message-ID: <50280@sun.uucp> Date: 21 Apr 88 02:00:23 GMT References: <9654@jplgodo.UUCP> <14020030@hpisod2.HP.COM> <887@cresswell.quintus.UUCP> Organization: Sun Microsystems, Inc. - Mtn View, CA Lines: 31 In article <887@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > In article <14020030@hpisod2.HP.COM>, decot@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@sun.com] frames to /dev/fb