Real and effective userids.

[Piercarlo Grandi]

In article <19915 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:

   In article <288 at bmers58.UUCP> davem at 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 at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk