/tmp versus temporary file types

[BALDWIN]

> As far as it relates to this /tmp business, we are discussing a security and
> integrity problem (I started this discussion) which is very visible,
> obviously we have lived this long w/o a solution, but I suspect we have paid
> intermittently with problems for administrators. It is also a very realistic
> criticism when, for example, choosing UNIX for a student environment
> (*my* real world, which probably involves more $$ and people than many who
> claim some monopoly on what the *real* world is -- side flame, sorry.)
> 
> We can live w/o this solution, maybe there just is no good solution in
> general, but we can't live with an attitude that nothing should ever change
> as some have proposed to this list. That would be suicide.

I agree with your last paragraph completely!  So how about this solution
that's already been done in 2.8BSD:  sticky dirs.  The problem is: /tmp
has to allow anyone to create files in it, but in standard UNIX, if you
can create a file, you can remove it too (write perm on dir).  You need
to give anyone the ability to create files, but only to remove their own.
BSD overloaded the sticky bit on dirs to mean:  in unlink(2), if the parent
has the sticky bit (t) set, only unlink if you OWN the file or the directory
(of course, you have to have write perms in the parent as always).  This is
an amazingly trivial change, and perms on dirs are different anyway (e.g.,
x means search).  It also seems to solve the /tmp problem.  To get a secure
tmp file, do open("/tmp/blat", O_CREAT|O_EXCL, 0600).  The file is completely
safe.  Is this an acceptable fix, or am I missing something?
-- 
						Michael Baldwin
						{at&t}!whuxl!mike