linux-kernel - rename("a", "b") would not always remove "a" on success. ?!!

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-next>] [day] [month] [year] [list]

Date:	Fri, 28 Oct 2011 17:25:57 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>
Cc:	Christian Engelmayer <christian.engelmayer@...quentis.com>
Subject: rename("a", "b") would not always remove "a" on success. ?!!

Hi,

One of my users stumbled over a problem when power failure
hit his system at rename() and the filesystem he uses
(I don't know which) ended up having both old and new
file names in the directory. Basically, he ended up with
one file with two hardlinks pointing to it.

IOW: the scenario does not require unlucky power offs
to reproduce, just "ln a b" would do.

In his case these two particular hardlinks were pointing
to rotated log files.

When system restarted, it eventually tried to rotate files
again, via rename("a", "b").
rename succeeded, but since they are hardlinks, rename
did NOT remove "a".
Which made the logger process very confused.

The user dug into it and discovered that SUS actually
specifies this insane behavior:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html

'If the old argument and the new argument resolve to either .... or different
directory entries for the same existing file, rename() shall return
successfully and perform no other action.'

It's incredible they had audacity to put such nonsense into standard.

The page says in "RATIONALE" section:

'The specification that if old and new refer to the same file is
intended to guarantee that:

rename("x", "x");

does not remove the file.'

Why didn't they just explicitly say that they actually want THIS
particular case to work correctly, not OTHER cases to be fucked up?!

Anyway. My question is, does it really need to be implemented in Linux?
It looks bogus to me, and it basically requires any program
to contain a work-around for this case. For example, mv from util-linux
apparently already has a workaround:

$ touch a; ln a b
$ strace mv a b
...
stat64("b", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat64("a", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat64("b", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
geteuid32()                             = 0
unlink("a")                             = 0
close(0)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?

-- 
vda
--
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/