In some mail from Peter 'Goober' Kosinar, sie said: [...] > How does it work - for each process it stores a new uid (I > have choosen a name RUID = Real UID). Purpose of RUID is to keep > track of who is real owner of this process (it is inherited from > parent process and changed only when root's process runs process > under different EUID). Sounds like what other OS's call the "audit uid" - you may want to consider this name change (auid) given that "real uid" already has meaning and/or extand the usage to be more than just for auditting but that might also be mixing purposes incorrectly. The main problem I see with this is as follows: There are programs which are setuid-root, and that need to be setuid-root, but for which the security status is unknown (this is most likely all setuid programs save for a few very small ones you can read the source for and understand yourself). It may be that during the course of the natural operation of one of these programs that it needs to run /bin/sh or otherwise start an external program. At this point, if you deny the transfer of privilege (at the execution of either the initial program or the sub-program it runs), you could well be interfering with its natural operation in such a way that you might as well "chmod u-s". Darren
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:55:36 PDT