double setuid programs

[utzoo!decvax!ucbvax!unix-wizards]

>From cbosgd!mark at Berkeley Wed Oct  7 18:35:34 1981
I've run up against a problem with programs running suid - suppose they
want to invoke another suid program, such as mkdir.  mkdir will apply
the REAL uid permissions instead of the effective uid, which is destroyed
by the suid bit.  Netnews is running up against this problem, since it
runs suid a non-root user ("newsuser"), and sometimes needs to do mkdirs
of subdirectories under one fixed parent directory: /usr/spool/news.
Here are the solutions I have to this problem, none of which is wonderful.
I would appreciate feedback from anyone who has a better solution.

(1) The parent directory in which the mkdirs are done is mode 777.  This
works, but the child directories get owned by the real uid, and there are
a number of paranoid systems around that won't permit any 777 directories
("If there's a 777 dir around, somebody might, God forbid, \put/ something
there!")

(2) The parent must be owned by newsuser, and is normally 755.  The program
doing the mkdir first chmods it to 777, then calls mkdir, then chmods it back.
This leaves a window during which somebody could make a file, if they were
fast, and they can invoke netnews in such a way as to force it to do the mkdir.
(But it leaves the dir there, there is no way to get rid of it.)

(3) A change to the kernel: suid bits are "stacked", that is, when an suid
file is exec'ed, before setting euid to owner(file), it sets ruid to euid.
This loses all traces of the original real uid, but might be a better way
to convey permissions.

(4) A different change to the kernel: allow setuid(geteuid()), which is
currently forbidden.  I have always thought this should be allowed anyway.
Does anyone know of any security holes this would open up?

	Mark Horton
	mark at berkeley