jmc (03/23/83)
I suppose that this is all old hat, and either this has been flogged to death already, or else there is a good reason, but why can I not do setuid(geteuid()); or for that matter setgid(getegid()); in standard unix if the effective uid is not the super-user? 1. "Mkdir" produces wrong (or unintended) ownership of directories when called from a setuid program. Usually results in directory not being created, unless higher level directory mode 777. 2. On system III, 'kill' has to have the effective uid matching the real uid of the destination process. If I want to have (as in our spooler package) a utility to send a message to a daemon process, the daemon process must have a well-defined real uid. (It could have been started by someone else, but is now printing my file). 3. The accounting software accounts by real uid, a bit unfair in the case of a spooler daemon if it starts off to print my one-page file, and whilst doing so someone puts up a 100-page spool file. All right, you say, make things setuid root, but who wants a situation where to develop non-critical software everyone has to know the root password? If the only user you can meaningfully setuid to is root, then something is wrong surely? I think we should either, in order of preference 1. Allow setuid(geteuid()) 2. Allow exchid() exchange effective/real ids (this is useful to revert to calling privileges to open a file, then back to effective uid). 3. Have a stack, setuser->effective user->real user->oblivion (cures mkdir, not sure what other implications would be). Please send your comments. Thanks. John Collins ...!mcvax!ukc!root44!jmc ...!edcaad!root44!jmc