[comp.sys.mips] sticky-bit directories not working?

gamiddle@maytag.waterloo.edu (Guy Middleton) (09/17/90)

On an M/2000 with 4.50:

	$ wmi
	news@xxx.mfcf (Group other) on ttyp0 at /usr/home/gamiddleton/tmp
	$ which mv
	/usr/bsd43/bin/mv
	$ ls -lgd
	drwxrwxrwt  2 root     staff         512 Sep 16 16:07 .
	$ ls -lg
	total 0
	-rw-r--r--  1 root     staff           0 Sep 16 16:07 blah
	-rw-r--r--  1 news     staff           0 Sep 16 16:08 foo
	$ mv blah foo
	mv: blah: rename: No permission match
	$ ls -lg
	total 0
	-rw-r--r--  2 root     staff           0 Sep 16 16:07 blah
	-rw-r--r--  2 root     staff           0 Sep 16 16:07 foo

Hmmm.  I just tried this with /bin/mv, and it work as expected (that is, it
didn't work at all).  This seems strange, since one would expect both programs
to work by using rename(2).

rogerk@mips.COM (Roger B.A. Klorese) (09/18/90)

In article <1990Sep16.202103.8263@maytag.waterloo.edu> gamiddle@maytag.waterloo.edu (Guy Middleton) writes:
>On an M/2000 with 4.50:
>
>	$ wmi
>	news@xxx.mfcf (Group other) on ttyp0 at /usr/home/gamiddleton/tmp
>	$ which mv
>	/usr/bsd43/bin/mv
>	$ ls -lgd
>	drwxrwxrwt  2 root     staff         512 Sep 16 16:07 .
>	$ ls -lg
>	total 0
>	-rw-r--r--  1 root     staff           0 Sep 16 16:07 blah
>	-rw-r--r--  1 news     staff           0 Sep 16 16:08 foo
>	$ mv blah foo
>	mv: blah: rename: No permission match
>	$ ls -lg
>	total 0
>	-rw-r--r--  2 root     staff           0 Sep 16 16:07 blah
>	-rw-r--r--  2 root     staff           0 Sep 16 16:07 foo
>
>Hmmm.  I just tried this with /bin/mv, and it work as expected (that is, it
>didn't work at all).  This seems strange, since one would expect both programs
>to work by using rename(2).

Sorry, I couldn't duplicate this:


Script started on Mon Sep 17 10:26:37 1990
csbug@servitude[1] whoami
csbug
csbug@servitude[2] ls -l /tmp/foo /tmp/bar
-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 /tmp/bar
-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 /tmp/foo
csbug@servitude[3] ls -ld /tmp
drwxrwxrwt   3 sys      sys        14848 Sep 17 10:26 /tmp
csbug@servitude[4] cd /tmp
csbug@servitude[5] mv foo bar
mv: cannot remove foo: Permission denied
csbug@servitude[6] /bsd43/bin/mv foo bar
override protection 644 for bar? y
mv: foo: rename: No permission match
csbug@servitude[7] ls -l foo bar
-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 bar
-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 foo
csbug@servitude[8] exit
csbug@servitude[9] 

script done on Mon Sep 17 10:27:26 1990
-- 
ROGER B.A. KLORESE                                  MIPS Computer Systems, Inc.
MS 6-05    930 DeGuigne Dr.   Sunnyvale, CA  94086              +1 408 524-7421
rogerk@mips.COM         {ames,decwrl,pyramid}!mips!rogerk         "I'm the NLA"
"Lead me not into temptation; I can find the way myself."      --Rita Mae Brown

rex@cs.su.oz (Rex Di Bona) (09/18/90)

In article <41541@mips.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes:
>In article <1990Sep16.202103.8263@maytag.waterloo.edu> gamiddle@maytag.waterloo.edu (Guy Middleton) writes:
>>On an M/2000 with 4.50:
>>
>>	$ wmi
>>	news@xxx.mfcf (Group other) on ttyp0 at /usr/home/gamiddleton/tmp
>>	$ which mv
>>	/usr/bsd43/bin/mv
>>	$ ls -lgd
>>	drwxrwxrwt  2 root     staff         512 Sep 16 16:07 .
>>	$ ls -lg
>>	total 0
>>	-rw-r--r--  1 root     staff           0 Sep 16 16:07 blah
>>	-rw-r--r--  1 news     staff           0 Sep 16 16:08 foo

Note: blah is owned by root, foo by news, this is very important.

>>	$ mv blah foo
>>	mv: blah: rename: No permission match

Yep, you cannot do this. You cannot remove blah, as you don't have the
permissions.

>>	$ ls -lg
>>	total 0
>>	-rw-r--r--  2 root     staff           0 Sep 16 16:07 blah
>>	-rw-r--r--  2 root     staff           0 Sep 16 16:07 foo

Ok, so the rename did the unlink on foo, and the link from blah to foo,
Sounds good to me.  Perhaps the bsd 'rename' is broken, as it should
have refused to do any of the operations? If 'real' bsd systems do
this, then this is how it shoud be (refer to the previous discussion
over bsd v. non-bsd programs; should a program in /bsd43/bin be bug for
bug compatible with a straight bsd program).

>>
>>Hmmm.  I just tried this with /bin/mv, and it work as expected (that is, it
>>didn't work at all).  This seems strange, since one would expect both programs
>>to work by using rename(2).

I am glad to see that the system V mv does the right thing...
Mark one up for system V over BSD :-) (ducks for cover)

>
>Sorry, I couldn't duplicate this:
>
>
>Script started on Mon Sep 17 10:26:37 1990
>csbug@servitude[1] whoami
>csbug
>csbug@servitude[2] ls -l /tmp/foo /tmp/bar
>-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 /tmp/bar
>-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 /tmp/foo

Note: both files are owned by rogerk, so csbug cannot acess either..

>csbug@servitude[3] ls -ld /tmp
>drwxrwxrwt   3 sys      sys        14848 Sep 17 10:26 /tmp
>csbug@servitude[4] cd /tmp
>csbug@servitude[5] mv foo bar
>mv: cannot remove foo: Permission denied
>csbug@servitude[6] /bsd43/bin/mv foo bar
>override protection 644 for bar? y
>mv: foo: rename: No permission match
>csbug@servitude[7] ls -l foo bar
>-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 bar
>-rw-r--r--   1 rogerk   mips           0 Sep 17 10:22 foo
>csbug@servitude[8] exit
>csbug@servitude[9] 
>
>script done on Mon Sep 17 10:27:26 1990
>-- 
>ROGER B.A. KLORESE                                  MIPS Computer Systems, Inc.
>MS 6-05    930 DeGuigne Dr.   Sunnyvale, CA  94086              +1 408 524-7421
>rogerk@mips.COM         {ames,decwrl,pyramid}!mips!rogerk         "I'm the NLA"
>"Lead me not into temptation; I can find the way myself."      --Rita Mae Brown

Script started on Tue Sep 18 11:48:00 1990
tmp:rex(moria): uname -A
moria moria 4_50 UMIPS mips rc2030 ATT_V3_0
tmp:rex(moria): > foo
tmp:rex(moria): > bar
tmp:rex(moria): ls -liasd . foo bar
    14    1 drwxrwxrwx   3 sys      sys          512 Sep 18 11:48 .
    72    0 -rw-------   1 rex      rex            0 Sep 18 11:48 bar
    58    0 -rw-------   1 rex      rex            0 Sep 18 11:48 foo
tmp:rex(moria): chmod 644 foo bar
tmp:rex(moria): chown root bar
tmp:rex(moria): ls -liasd . foo bar
    14    1 drwxrwxrwx   3 sys      sys          512 Sep 18 11:48 .
    72    0 -rw-r--r--   1 root     rex            0 Sep 18 11:48 bar
    58    0 -rw-r--r--   1 rex      rex            0 Sep 18 11:48 foo
#
#ok, we first set up the directory with mode 777 (note, no sticky bit)
#
tmp:rex(moria): /bin/mv bar foo (/bsd43/bin/mv bar foo works too)
tmp:rex(moria): ls -lias bar foo
bar: No such file or directory
    72    0 -rw-r--r--   1 root     rex            0 Sep 18 11:48 foo
#
#Yep, it works as it should
#
tmp:rex(moria): rm foo
foo: 644 mode ? y
tmp:rex(moria): > bar
tmp:rex(moria): > foo
tmp:rex(moria): chmod 644 foo bar
tmp:rex(moria): chown root bar
#
# so, set on the sticky bit and repeat
#
tmp:rex(moria): s chmod 1777 .
tmp:rex(moria): ls -liasd . foo bar
    14    1 drwxrwxrwt   3 sys      sys          512 Sep 18 11:50 .
    58    0 -rw-r--r--   1 root     rex            0 Sep 18 11:50 bar
    72    0 -rw-r--r--   1 rex      rex            0 Sep 18 11:50 foo
#
# system V /bin/mv refuses, as bar would not be removable.
#
tmp:rex(moria): /bin/mv bar foo
mv: cannot remove bar: Permission denied
tmp:rex(moria): ls -liasd . foo bar
    14    1 drwxrwxrwt   3 sys      sys          512 Sep 18 11:50 .
    58    0 -rw-r--r--   1 root     rex            0 Sep 18 11:50 bar
    72    0 -rw-r--r--   1 rex      rex            0 Sep 18 11:50 foo
#
# bsd mv gets part way there, it removed my file, and did the link
# (both it could do because of the 'w' permission. But it couldn't do
# the unlink because of the 't' sticky bit. (check the inode numbers).
#
tmp:rex(moria): /bsd43/bin/mv bar foo
mv: bar: rename: No permission match
tmp:rex(moria): ls -liasd . foo bar
    14    1 drwxrwxrwt   3 sys      sys          512 Sep 18 11:51 .
    58    0 -rw-r--r--   2 root     rex            0 Sep 18 11:50 bar
    58    0 -rw-r--r--   2 root     rex            0 Sep 18 11:50 foo
tmp:rex(moria): 
script done on Tue Sep 18 11:51:24 1990

It appears, as I've mentioned, that the bsd 'rename' just calls unlink,
link, and unlink. (All within the kernel so that the second file always
exists). Perhaps Roger can get this checked out.

		Rex.
-------
Penguin Lust is NOT immoral.	rex@cs.su.oz.au		(+61 2 692 4174)

rogerk@mips.COM (Roger B.A. Klorese) (09/18/90)

In article <1206@cluster.cs.su.oz.au> rex@cluster.cs.su.oz (Rex di Bona) writes:
>It appears, as I've mentioned, that the bsd 'rename' just calls unlink,
>link, and unlink. (All within the kernel so that the second file always
>exists). Perhaps Roger can get this checked out.

I've gone as far as I could tonight; I was about to post about the error in
my test case, but Rex has beaten me to it.  I suspect that iaccess() is
telling rename() that it can write the source file's inode when it in fact
cannot (or at least cannot remove the source); more checking tomorrow.
-- 
ROGER B.A. KLORESE                                  MIPS Computer Systems, Inc.
MS 6-05    930 DeGuigne Dr.   Sunnyvale, CA  94086              +1 408 524-7421
rogerk@mips.COM         {ames,decwrl,pyramid}!mips!rogerk         "I'm the NLA"
"Lead me not into temptation; I can find the way myself."      --Rita Mae Brown