Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!math.fu-berlin.de!tmpmbx!scuzzy!src
From: src@scuzzy.in-berlin.de (Heiko Blume)
Newsgroups: comp.unix.admin
Subject: Re: Possible security problem, need information..
Message-ID: <1991Mar24.151601.18097@scuzzy.in-berlin.de>
Date: 24 Mar 91 15:16:01 GMT
References: <1991Mar19.194216.5763@kithrup.COM> <873@optima.cs.arizona.edu> <1991Mar22.000333.22597@scuzzy.in-berlin.de> <1991Mar22.164302.
Organization: Contributed Software
Lines: 33

jik@athena.mit.edu (Jonathan I. Kamens) writes:

>In article <1991Mar22.000333.22597@scuzzy.in-berlin.de>, src@scuzzy.in-berlin.de (Heiko Blume) writes:
>|> # mv test2 test
>|> mv: test: 644 mode?y
>|> mv: cannot unlink .
>|> mv: permission denied
>|> 
>|> 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.

ISC 2.2.1 does have rename(2) [btw: it even passed the POSIX compliance test
suite (PCTS 1.0) of NIST], but who knows if mv uses it?

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

sure, i just wondered why it said '.' instead of 'test'.

>  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.

that's what i guess/hope now, too. wouldn't be too nice if it really
tried to unlink(".") ....
-- 
      Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
                  public UNIX source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home