Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!sdd.hp.com!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.admin
Subject: Re: Possible security problem, need information..
Message-ID: <1991Mar22.164302.11122@athena.mit.edu>
Date: 22 Mar 91 16:43:02 GMT
References: <1991Mar19.194216.5763@kithrup.COM> <873@optima.cs.arizona.edu> <1991Mar22.000333.22597@scuzzy.in-berlin.de>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 29

In article <1991Mar22.000333.22597@scuzzy.in-berlin.de>, src@scuzzy.in-berlin.de (Heiko Blume) writes:
|> # [ls]
|> drwxrwxrwt  15 root     root         880 Mar 22 00:44 /tmp
|> -rw-r--r--   1 root     other          4 Mar 22 00:39 /tmp/test
|> -rw-r--r--   1 src      src            5 Mar 22 00:39 /tmp/test2
|> # mv test2 test
|> mv: test: 644 mode?y
|> mv: cannot unlink .
|> mv: permission denied
|> 
|> so the sticky bit works (i tried cp test2 test, echo bla>>test etc too),
|> but what does the 'mv: cannot unlink .' mean???? ain't got no clue...

  My guess is that you're working on a system that does not have a rename
system call, so mv works by unlinking the target name, if it exists, then
creating a hard link from the old source name to the target name, then
unlinking the old source name.

  Since /tmp/test is owned by root, mv can't unlink it.

  Although there appears to be a bug in your version of mv, because it tried
to print the filename and failed.  Probably a missing argument to fprintf or
something.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710