sticky bit directory

[Hannu-Matti J{rvinen]

First as user hmj I create directory test with permissions described
above.  Then I make an ordinary file (file1).  This sequence is made on
4.0.1 on local disk, but NFS disck works same way.

% mkdir test
% chmod 7777 test
% ls -lsd test
   1 drwsrwxrwt  2 hmj           512 Jan 19 16:59 test/
% cd test
% touch file1
% ls -ls
total 0
   0 -rw-r--r--  1 hmj             0 Jan 19 17:00 file1
% 

Then I changed my role to user ks and used cd to get the previous
directory.  I should have included the fact that you have to be a
different user than the owner of the files. In fact, this makes the
problem even worse.

% ls -ls
total 0
   0 -rw-r--r--  1 hmj             0 Jan 19 17:00 file1
% mv file1 file2
mv: file1: rename: Not owner
(Yes, you were right, it is rename, but how would you explain the following, if my
guess was wrong?)
% ls -lsi
total 0
 53392    0 -rw-r--r--  2 hmj             0 Jan 19 17:00 file1
 53392    0 -rw-r--r--  2 hmj             0 Jan 19 17:00 file2
%

So rename refuses but something makes the link anyway.  This works for
directories, too. I am NOT going to demonstrate it, because unlink (see
man 8 unlink) won't remove it (but I agree, it should). I haven't tried
unlink(2), but according to the manual page of unlink(8) that test should
be unnecessary.

Hannu-Matti Jarvinen, Tampere University of Technology, Finland
hmj at tut.fi, hmj at tut.uucp, hmj at tut.funet (tut.ARPA is not the same computer).

[[ My guess is that this is a bug in the "rename" system call.  It should
be doing more thorough permission checks before starting *anything* in the
rename.  A rename seems like it would be simple enough:  just change the
string in the directory.  However, due to various Unix idiosyncrasies, the
"rename" system call really does pretty much just the same thing as
'unlink("new"); link("old", "new"); unlink("old");' (at least in 4.3).
--wnl ]]