linux-kernel - Re: unexpected rename() behaviour

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47EE2072.7000504@froyn.name>
Date:	Sat, 29 Mar 2008 11:56:50 +0100
From:	Ketil Froyn <ketil@...yn.name>
To:	"J.A. Magallón" <jamagallon@....com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: unexpected rename() behaviour

J.A. Magallón skrev:
> On Sat, 29 Mar 2008 01:07:52 +0100, Ketil Froyn <ketil@...yn.name> wrote:
> 
>> Hi,
>>
>> The following behaviour was unexpected (tested on Debian/ext3):
>>
>> $ echo 1 > 1
>> $ ln 1 2
>> $ cat 2
>> 1
>> $ ./rename 2 1
>> $ echo $?
>> 0
>> $ cat 2
>> 1
>>
>> The code for ./rename is simple:
>>
>> ---
>> /* compile: gcc -o rename rename.c */
>> #include <stdio.h>
>> int main(int argc, char *argv[]) { return rename(argv[1], argv[2]); }
>> ---
>>
>> I thought this must be wrong behaviour, but I have been unable to 
>> confirm what the correct result should be in this special case. rename() 
>> returns success, but the source file is intact, which seems odd. The 
>> "mv" command specifically checks for cases like this and calls 
>> unlink("2") instead of rename("2", "1"). Are all applications meant to 
>> do this? What standards describe what rename() should do in cases like this?
>>
> 
> man 2 rename:
> 
>        If  oldpath  and  newpath are existing hard links referring to the same
>        file, then rename() does nothing, and returns a success status.
> 
> That's why mv checks the special case.

This was not in my (Debian 4.0) version of the man page. I assume it is 
listed in the DESCRIPTION section and not the BUGS section.

Is this a corner case undefined by POSIX, for instance, or does POSIX 
explicitly say that this is the correct behaviour? I have verified that 
the same happens on BSD, but I still find it odd that a successful 
rename(oldpath,newpath) should leave oldpath in place.

So given the case that it is a requirement that oldpath should be 
removed after the rename(), does all software need to check whether 
oldpath and newpath are existing hard links referring to the same file, 
and if so, call unlink(oldpath) instead? I would guess that lots of 
existing software doesn't.

Regards,
Ketil Froyn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/