Unix files should have both real and effective ids for files too

[Piercarlo Grandi]

In article <109958 at convex.convex.com> tchrist at convex.COM (Tom
Christiansen) writes:

tchrist> I consider non-superuser chown(2)s harmful.  They screw up
tchrist> anyone who's trying to do post-facto disk accounting or
tchrist> pre-emptive disk quotas.

On 7 Dec 90 11:12:57 GMT, brnstnd at kramden.acf.nyu.edu (Dan Bernstein)
commented:

brnstnd> There is, however, one case where non-superuser chown()s would
brnstnd> greatly help security. Setuid programs should to be able to
brnstnd> switch files between the real and effective uids. Because this
brnstnd> feature isn't available, many secure programs have to run as
brnstnd> root rather than their own uids.

This is true, except that the whole setuid mechanism of UNIX is flawed
or incomplete. As you have remarked, some systems idiotically apply the
maximum process limit per uid to the _effective_ uid...

More interestingly, I have reasoned years ago about the chown(2)
problem, and I have found the solution to both Christiansen's and
Bernstein's concerns. It is very simple, and shows that the UNIX
ownership mechanism is incomplete.

Files should be like processes and have BOTH an effective and a real
user id. Accounting would be based on the real id, and protection on the
effective id.

Transfer of files between two ids would be easily and safely
accomplisehd if we allow a process running under one of the ids to set
the other to be the same.

Suppose that id A wants to pass ownership of a file to B; it would
first change the euid of the file to B, and then B would change the ruid
of the file to B too.

This is not dangerous at all; B gets to pay for the file only if it
wants to acquire its ownership. A, if B fails to change the real id to
itself, can revert the euid to itself again.

In other words: Unix files are exactly like process, they exist in two
different dimensions, accounting and protection, and each must have its
own id.

Note that having real and effective id for files too also solves the
problem of protection and accounting for space for protected subsystems
like Ingres or LPD, which currently have three equally unpalatable
choices: if they hold the files entrusted to them under the user's id
they must run either as root or must make them readable/writable to
everybody to be able to access them; if they change ownership to
themselves then the user can no longer access them and also does not pay
for the space it occupies.

Final observation: adding read/effective user ids to any UNIX kernel
probably requires half a dozen lines spread across a couple of headers
and in the stat(2) implementation, a few recompilations, and
reformatting and reloading filesystems. Frankly not a lot of work.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk