Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!bloom-beacon!eru!luth!sunic!mcsun!ukc!dcl-cs!aber-cs!thor!pcg From: pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.wizards Subject: Re: Real and effective userids. Message-ID:Date: 3 Oct 89 13:53:53 GMT References: <288@bmers58.UUCP> <19915@mimsy.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 57 In-reply-to: chris@mimsy.UUCP's message of 1 Oct 89 06:33:36 GMT In article <19915@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: In article <288@bmers58.UUCP> davem@bmers58.UUCP (Dave Mielke) writes: >Can anyone tell me what the "official" distinction is between the real >userid and the effective userid of a process is? When a file is created >its owner is set to the effective userid of the creating process, >whereas when a file is accessed it would appear that the real userid of >the accessing process is used when performing the authorization check. The `raisin de eatery' (I never could spell in French :-) ) of the real UID is to allow setuid programs to know who invoked them. It is used for virtually nothing else.% It is up to setuid programs to do authorisation tests, preferably by using setreuid() to swap IDs, doing the operation, and using setreuid() to swap back. (In SysV, where setreuid() is not available, saved setuid works for everyone but root.) The rest, obviously, depends on the setuid program. ----- % access(), setuid(), setreuid(), and getuid() refer to the real uid. This is not guaranteed to be a complete list. Let me be more precise. The difference is that one is used for accounting, the other for protection. Suppose that the distinction did not exist; then running a setuid program would be debited to its author, not its invoker (this would force every setuid program to do its own accounting, and charging for its use, which is almost never appropriate). In other words, a process executes in several "planes" at once (e.g. accounting, protection, but could also be priority, for example), and they need not be the same. An obvious generalization is to have real (accounting) and effective (protection) owners for files as well. This would solve some problems with file ownership and accounting for closed subsystems (notably ingres and the spoolers) that implement their own protection policies, and thus need to give access to files only to their own setuid programs, but do not want the space taken up to be debited to them. Now many people, especially from Universities, think that accounting and charging for resources is not important; I have actually come to the conclusion that is is damn important (even if it is purely notional) on two grounds: 1) for performance evaluation 2) an elegant charging architecture is a good corroboration that the overall os architecture is good. Let me leave the second point just an hint... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk