bug#20597: ‘unlinkat’ bug in Linux 4.0.2 leads to tar test failure

["Pádraig Brady" <P@draigBrady.com>]

On 24/05/15 14:53, Ludovic Courtès wrote:
> Pádraig Brady <P@draigBrady.com> skribis:
> 
>> On 24/05/15 12:33, Ludovic Courtès wrote:
> 
> [...]
> 
>>> unlinkat(4, "foo_file", 0)              = 0
>>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0
>>> unlinkat(5, "bar_file", 0)              = 0
>>> unlinkat(4, "../bar", AT_REMOVEDIR)     = -1 ENOENT (No such file or directory)
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Contrast this with the same thing on 4.0.4-gnu:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> unlinkat(4, "foo_file", 0)              = 0
>>> unlinkat(AT_FDCWD, "foo", AT_REMOVEDIR) = 0
>>> unlinkat(5, "bar_file", 0)              = 0
>>> unlinkat(4, "../bar", AT_REMOVEDIR)     = 0
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> So this looks like a 4.0.2 kernel bug that Gnulib’s unlinkat should
>>> perhaps work around.
>>>
>>> Thoughts?
>>
>> Maybe. How widely deployed was 4.0.2 (It's not used in Red Hat land for example).
>> How many versions was the bug present for?
> 
> I don’t know, and I haven’t been able to find traces of a fix in that
> area in the kernel.
> 
> OTOH, after rereading the analysis at
> <http://lists.gnu.org/archive/html/bug-tar/2014-08/msg00010.html>, it
> may be that the 4.0.2 behavior is POSIX-conforming, in which case we’d
> rather fix tar (or its tests) instead:
> 
>   The BSD behavior appears to be in line with POSIX.  unlinkat() with
>   AT_REMOVEDIR is equivalent to rmdir(), whose specification says:
> 
>     If one or more processes have the directory open when the last
>     link is removed, the dot and dot-dot entries, if present, shall
>     be removed before rmdir() returns and no new entries may be created
>     in the directory, but the directory shall not be removed until
>     all references to the directory are closed.
> 
>   Without "..", the path resolution of the subsequent unlinkat() call
>   should--or at least can--fail.
> 
> WDYT?

Yes I agree, either behavior is possible

thanks,
Pádraig