msc@qubix.UUCP (Mark Callow) (12/19/83)
Almost every suid program has problems with having the correct
access rights at the right time during the program. For example
uucp cannot read your files if they have mode 640 because it runs
suid uucp.
Another example is tip which, although making an effort
to get it right, still has problems. If your /usr/spool/uucp has
mode 755 tip cannot remove the lock file it creates there because,
after it creates, it it changes back to the real uid so that it can
read your files etc.
All these problems come down to not having the correct 1 of
2 sets of access permissions at a given time. There seems to be
a very simple solution. Give suid programs the access permissions
of both the real and effective id's AT THE SAME TIME.
This seems so blindingly obvious that there must be some fatal flaw
in the idea since I've never seen it mentioned before. I'm interested
in anyone's comments on this idea. I'd be especially interested in
Dennis Ritchie's comments as the holder of the patent on the suid scheme.
--
From the Tardis of Mark Callow
msc@qubix.UUCP, decwrl!qubix!msc@Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!mscdee@cca.UUCP (Donald Eastlake) (12/19/83)
There is probably some problem with Mark Callow's idea of suid programs
having both real and effective id permissions simultaneously but if
so why not just have two different flavors of set u id, one like now
and one that makes you have both sets of permissions? The only thing
you have to decide is which set to surpress when someone tries to chain
these things.
+ Donald E. Eastlake, III
ARPA: dee@CCA-UNIX usenet: {decvax,linus}!cca!deewls@astrovax.UUCP (William L. Sebok) (12/20/83)
> All these problems come down to not having the correct 1 of > 2 sets of access permissions at a given time. There seems to be > a very simple solution. Give suid programs the access permissions > of both the real and effective id's AT THE SAME TIME. > > This seems so blindingly obvious that there must be some fatal flaw > in the idea since I've never seen it mentioned before. I would like to second this idea. I've thought of the idea myself and have thought of bringing it up some time (i.e. throwing myself before the wolf-pack). Logically it makes sense: the person running the program has given his permission to access his files by the fact that he is running the program, and the person who owns the program and set the suid on it has given the program permission to access her files by the fact that she set the suid bit on the program (how's that for gender balance?). In effect the program has both permissions anyway, only not at the same time. I see no security hole that isn't there already in having these permissions available at the same time. Then programs wouldn't have to go through the contortions that they do when they have to manipulate both sets of files, the program's and the user's. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton,vax135}!astrovax!wls
lee@fortune.UUCP (12/21/83)
I don't see any problem with reading or executing files.
But how are we going to handle ownership of new files?
Do new files belong to real user or effective user?
Do we need a new system call to switch between real user
and effective user ownership? Ops, is this bringing in
more problems than what it is trying to solve? How are
we going to convince UNIX old timers to change their programs
(please read the on-going discussion with 4.2 signals ).
c / Ed Lee
C. /_. {amd70, ihnp4, harpo}!fortune!leelee@fortune.UUCP (12/21/83)
#R:qubix:-71600:fortune:11600034:000:517
fortune!lee Dec 20 14:22:00 1983
I don't see any problem with reading or executing files.
But how are we going to handle ownership of new files?
Do new files belong to real user or effective user?
Do we need a new system call to switch between real user
and effective user ownership? Ops, is this bringing in
more problems than what it is trying to solve? How are
we going to convince UNIX old timers to change their programs?
(please read the on-going discussions with 4.2 signals ).
c / Ed Lee
C. /_. {amd70, ihnp4, harpo}!fortune!leewls@astrovax.UUCP (William L. Sebok) (12/21/83)
> I don't see any problem with reading or executing files. > But how are we going to handle ownership of new files? > .... Ed Lee I don't see the problem with incompatability. File ownership would be handled just like before (i.e. the effective uid). -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton,vax135}!astrovax!wls
guy@rlgvax.UUCP (Guy Harris) (12/21/83)
Note 1: The effective UID is what is used both as the user ID to determine
permissions (including super-user privileges) and as the user ID which will
own all files created by the process. The real UID is used only for:
1) kernel accounting
2) dropping cores; if real UID != effective UID, no "core" file
is created if the process gets a signal that would normally
cause a "core" file to be written
3) various other UNIX-version dependent things
Note 2: System V provides much of what is needed. The rules are:
You (i.e., any program, whether it has super-user privileges or
not) may set your effective uid to any non-superuser ID that is
either:
your real uid
or:
the uid your program was originally set-UID to
This does NOT set the real UID, only the effective UID. In effect, you can
switch back and forth between having the privileges of (and creating files
owned by) the original user and having the privileges of the set-UID user.
Only the superuser can set the real uid.
This is not documented; after all, if all the useful features were
documented, would it be UNIX? It is, however, closer to the right way
to do it than the old way, as it permits a program to alternate between
using the privileges of the "real" and "set-UID" UID.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guymason@utcsrgv.UUCP (Dave Mason) (12/22/83)
Ed Lee asks who new files belong to if a suid program has both real user
and effective user ids. If Set Dual ID (sdid) were a separate bit from
suid, then the suid bit would determine who owned any created files, and
sdid would determine access rights for existing files. Having both bits
also supports existing programs.
--
-- Dave Mason, U. Toronto CSRG,
{utzoo,linus,cornell,watmath,ihnp4,allegra,floyd,decwrl,
decvax,uw-beaver,ubc-vision}!utcsrgv!masongwyn%brl-vld@sri-unix.UUCP (12/23/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> UNIX System V SCCS utilities rely on the UID rules you described to permit a set-UID-to-archive-owner access interface program to allow controlled access to SCCS archives. Without the ability to change effective UID back to the original set-UID value, z.* lock files cannot be removed from the archive directory since at that point the process has the real UID for its effective UID (to create extracted sources with appropriate ownership). I discovered this the hard way and am trying to figure out how to work around the problem on the non-USG systems I have access to.
edhall%rand-unix@sri-unix.UUCP (12/24/83)
The SYS/V suid mechanism sounds like a winner, as long as system programmers are wary of security implications. Berkeley, are you listening? [I wonder what the implications are for Dennis Ritchie's patent on suid? I suppose the mechanism is still covered.] -Ed Hall edhall@rand-unix (ARPA) decvax!randvax!edhall (UUCP)
edhall%rand-unix@sri-unix.UUCP (12/24/83)
Concerning your problem with emulating the USG suid mechanism on non- suid programs: I once accomplished this sort of thing by having the program spawn a child process which setuid()'d back to the real UID, leaving the parent to clean up after the child died. Of course, the parent must be very careful with signals and the whole thing isn't the most efficient technique in the world, but with vfork() things aren't quite so bad. Now, if UNIX had coroutines... :-) -Ed edhall@rand-unix.ARPA decvax!randvax!edhall.UUCP