Path: utzoo!attcan!uunet!lll-winken!ames!husc6!rice!sun-spots-request
From: mcvax!tikli!hmj@uunet.uu.net (Hannu-Matti J{rvinen)
Newsgroups: comp.sys.sun
Subject: Re: sticky bit directory
Message-ID: <5805@etana.tut.fi>
Date: 25 Jan 89 08:33:41 GMT
References: <5761@etana.tut.fi>
Sender: usenet@rice.edu
Organization: Tampere University of Technology, Finland
Lines: 49
Approved: Sun-Spots@rice.edu
Original-Date: 19 Jan 89 15:36:50 GMT
X-Sun-Spots-Digest: Volume 7, Issue 120, message 2 of 9
X-Issue-Reference: v7n108

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@tut.fi, hmj@tut.uucp, hmj@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 ]]