Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.internals Subject: Unix files should have both real and effective ids for files too Message-ID: Date: 10 Dec 90 19:17:50 GMT References: <1990Dec5.135759.12508@noao.edu> <1990Dec6.005358.6336@dg-rtp.dg.com> <109958@convex.convex.com> <14526:Dec711:12:5790@kramden.acf.nyu.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 63 Nntp-Posting-Host: odin In-reply-to: brnstnd@kramden.acf.nyu.edu's message of 7 Dec 90 11:12:57 GMT In article <109958@convex.convex.com> tchrist@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@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@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk