linux-kernel - Re: RFC: allow empty symlink targets

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]

Date:	Wed, 15 May 2013 21:48:53 +0100
From:	Pádraig Brady <P@...igBrady.com>
To:	Eric Blake <eblake@...hat.com>, linux-api@...r.kernel.org,
	Alexander Viro <aviro@...hat.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: RFC: allow empty symlink targets

On 05/15/2013 03:40 PM, Eric Blake wrote:
> On 05/15/2013 06:38 AM, Pádraig Brady wrote:
>> On 01/17/2013 04:22 PM, Pádraig Brady wrote:
>>> On 01/17/2013 01:03 PM, Pádraig Brady wrote:
>>>> The discussion leading to this is at http://bugs.gnu.org/13447
>>>> In summary other systems allow an empty target for a symlink,
>>>> and POSIX specifies that it should be allowed?
>>>
>>> In relation to this, Eric Blake said:
>>>
>>>> In today's Austin Group meeting, I was tasked to open a new bug that
>>>> would state specifically how the empty symlink is resolved; the intent
>>>> is to allow both Solaris behavior (current directory) and BSD behavior
>>>> (ENOENT).  Meanwhile, everyone was in agreement that the Linux kernel
>>>> has a bug for rejecting the creation of an empty symlink, but once that
>>>> bug is fixed, then Linux can choose either Solaris or BSD behavior for
>>>> how to resolve such a symlink.
>>>>
>>>> It will probably be a bug report similar to this one, which regarded how
>>>> to handle a symlink containing just slashes:
>>>> http://austingroupbugs.net/view.php?id=541
>>
>> Following up from http://austingroupbugs.net/view.php?id=649
>> It seems POSIX will now allow the current Linux behavior of returning ENOENT,
> 
> Huh?  Linux currently doesn't allow the creation of an empty symlink.
> That link mentions the current BSD behavior of returning ENOENT when
> resolving such a symlink (that is, what stat() does when chasing through
> an empty symlink, provided such a symlink is first created).

Ah OK. The standards are hard enough to interpret,
never mind the comments discussing the standards :)
Not helping was that symlink() returns ENOENT in this case too.

>> or the Solaris behavior of allowing empty symlink targets.
> 
> The point made in that bug report is that Linux is buggy for not
> allowing symlink() to create an empty symlink in the first place; once
> you allow the creation of an empty symlink, then how to handle such a
> symlink in stat() is up to you whether to copy Solaris' or BSD's example.

OK cool, that make more sense to me.

Adding in a couple more recipients to garner interest...

thanks,
Pádraig.
--
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/