RFC: allow empty symlink targets

RFC: allow empty symlink targets

[Pádraig Brady]

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?

thanks,
Pádraig.

[PATCH] symlink: allow an empty target string

[Pádraig Brady]

POSIX only states that ENOENT should be returned
if an empty string is specified for the link name.
In fact it states the link target...
"shall be treated only as a character string and
 shall not be validated as a pathname".

Signed-off-by: Pádraig Brady <P@draigBrady.com>
---
 fs/namei.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 43a97ee..26dd264 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3533,12 +3533,13 @@ SYSCALL_DEFINE3(symlinkat, const char __user *, oldname,
 		int, newdfd, const char __user *, newname)
 {
 	int error;
+	int empty;
 	struct filename *from;
 	struct dentry *dentry;
 	struct path path;
 	unsigned int lookup_flags = 0;
 
-	from = getname(oldname);
+	from = getname_flags(oldname, LOOKUP_EMPTY, &empty);
 	if (IS_ERR(from))
 		return PTR_ERR(from);
 retry:
-- 
1.7.6.4

Re: RFC: allow empty symlink targets

[Pádraig Brady]

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

thanks,
Pádraig.

Re: RFC: allow empty symlink targets

[Pádraig Brady]

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,
or the Solaris behavior of allowing empty symlink targets.

cheers,
Pádraig.

Re: RFC: allow empty symlink targets

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

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

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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: RFC: allow empty symlink targets

[Pádraig Brady]

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.

Re: RFC: allow empty symlink targets

[Pavel Machek]

Hi!

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

What happens when Linux tries to follow symlink created by
BSD/Solaris? I'm sure BSDs can write ext2 and we can read some BSD
filesystems...
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: RFC: allow empty symlink targets

[Al Viro]

On Wed, May 15, 2013 at 01:38:48PM +0100, P??draig Brady wrote:
> >> 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.

Austin Group Is At It Again, Demands at 11...

Would you mind explaining who's "everyone" and why would we possibly
want to honour that agreement of yours?  Functionality in question is
utterly pointless, seeing that semantics of such symlinks is OS-dependent
anyway *and* that blanket refusal to traverse such beasts is a legitimate
option.  What's the point in allowing to create them in the first place?

Re: RFC: allow empty symlink targets

[Pádraig Brady]

On 05/15/2013 11:03 PM, Al Viro wrote:
> On Wed, May 15, 2013 at 01:38:48PM +0100, P??draig Brady wrote:
>>>> 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.
> 
> Austin Group Is At It Again, Demands at 11...
> 
> Would you mind explaining who's "everyone" and why would we possibly
> want to honour that agreement of yours?  Functionality in question is
> utterly pointless, seeing that semantics of such symlinks is OS-dependent
> anyway *and* that blanket refusal to traverse such beasts is a legitimate
> option.  What's the point in allowing to create them in the first place?

That's a fair point.
I guess the main reason to allow is for consistency with
other systems that do allow it.

What triggered this was a user who was using ln to
store "non file name" strings in symlinks,
and was surprised by the Linux error here,
and annoyed by the non portability of his script.

cheers,
Pádraig.

Re: RFC: allow empty symlink targets

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 6423 bytes --]

On 05/15/2013 04:03 PM, Al Viro wrote:
> On Wed, May 15, 2013 at 01:38:48PM +0100, P??draig Brady wrote:
>>>> 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.
> 
> Austin Group Is At It Again, Demands at 11...
> 
> Would you mind explaining who's "everyone" and why would we possibly
> want to honour that agreement of yours?

That was "everyone" on the phone call at that particular Austin Group
meeting where the bug was discussed, and "everyone" that subscribes to
the Austin Group mailing list but raised no further objections during
the 30-day window when the resolution to the bug was discussed.

>  Functionality in question is
> utterly pointless, seeing that semantics of such symlinks is OS-dependent
> anyway *and* that blanket refusal to traverse such beasts is a legitimate
> option.  What's the point in allowing to create them in the first place?

The point was that POSIX has _always_ required the ability to create an
empty symlink.  For example, going back to POSIX 2001 (SUSv3):

http://pubs.opengroup.org/onlinepubs/009695399/functions/symlink.html
"The symlink() function shall create a symbolic link called path2 that
contains the string pointed to by path1 ( path2 is the name of the
symbolic link created, path1 is the string contained in the symbolic link)."
"The string pointed to by path1 shall be treated only as a character
string and shall not be validated as a pathname."
"[ENOENT]
    A component of path2 does not name an existing file or path2 is an
empty string."
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html
"3.367 String A contiguous sequence of bytes terminated by and including
the first null byte."

The wording is similar in POSIX 2008 (SUSv4, and untouched in POSIX
2013, released earlier this year as a technical corrigendum against
POSIX 2008).  Nothing in there says that path1 cannot be an empty
string.  An empty path1 must not be interpreted as an impossible file
name, so there should be no reason that symlink() cannot create it.
ENOENT is only permitted to be returned for a failure on path2, not on
path1.  Likewise, nothing in the POSIX standard says that readlink()
cannot return 0 as a valid length on an empty symlink.

The bug mentioned earlier in this thread
(http://austingroupbugs.net/view.php?id=649) was NOT about whether
creating an empty symlink should be allowed, but about what POSIX later
requires when encountering such an empty symlink during pathname
resolution.  Yes, to describe that behavior, you first have to create an
empty symlink - but all POSIX-certified OS have always allowed you to do
so; where they differed was on what happens when you stat() the symlink.
 The previous POSIX wording implied that dereferencing through an empty
symlink required you to start lookup traversal from the root directory,
which didn't match either existing behavior (traversal from the current
directory [Solaris], or failing with ENOENT [BSD]); so the bug was about
fixing the wording of pathname resolution to match existing practice for
systems that already easily permit empty symlinks - the behavior of
Linux was not considered during that bug fix only because we could not
easily test what Linux would do in that case due to the earlier problem
with symlink() non-compliance.

As I was on that particular phone call, I can also state that at the
time the bug was discussed, another argument was also raised: since it
is possible to create an empty symlink in other OS, and then mount that
filesystem under Linux, the Linux kernel ALREADY has to decide what to
do when dereferencing an empty symlink.  This is not as easy to set up,
so it was not tested when developing the bug fix for the stat() issue.
But the comments during the phone call were that the Linux behavior of
preventing the creation of an empty symlink on the grounds that "a
future stat() might have issues" were treated as a strawman argument,
since Linux would already have to deal with empty symlinks when mounting
a foreign file system.  Furthermore, the discussion focused on the text
I quoted above that shows that Linux has already been at odds with what
POSIX has already required for many years, and no one at the time was
willing to change that behavior without good reason.  In short, Linux
has ALWAYS had a POSIX-compliance bug with regards to its refusal to
create an empty symlink, and the bug mentioned above does not change
that fact, it only changed the standard to have a more sensible
requirement on what happens when dereferencing an empty symlink.

If you would like to file a bug against POSIX requesting that the next
version of POSIX permit implementations to reject an empty path1 in the
symlink() call on the grounds that you are unable to fix the Linux
kernel symlink() behavior to comply with existing POSIX wording, be my
guest.  The bug process is open, and anyone can file a bug, although I
don't know that I want to do it on your behalf.  Here's where you would
do it: http://austingroupbugs.net/

At the end of the day, I personally don't care whether you fix the Linux
kernel symlink() to allow empty symlinks, or successfully argue for a
bug fix against POSIX to permit the existing Linux symlink() behavior.
I'd love to see for Linux obtain POSIX certification someday, and either
of those two courses of action would get us closer.  Meanwhile, I know
there are enough other issues in the kernel (implementing O_SEARCH, for
example) that it will be a long time before we ever get a POSIX
certification of a Linux system.  And as long as Linux doesn't have
POSIX certification, corner cases like non-compliance with a requirement
that has been around for more than 12 years won't make life any harder
for people that already have to be aware that not all the world is POSIX.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: RFC: allow empty symlink targets

[Pavel Machek]

On Wed 2013-05-15 23:03:35, Al Viro wrote:
> On Wed, May 15, 2013 at 01:38:48PM +0100, P??draig Brady wrote:
> > >> 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.
> 
> Austin Group Is At It Again, Demands at 11...
> 
> Would you mind explaining who's "everyone" and why would we possibly
> want to honour that agreement of yours?  Functionality in question is
> utterly pointless, seeing that semantics of such symlinks is OS-dependent
> anyway *and* that blanket refusal to traverse such beasts is a legitimate
> option.  What's the point in allowing to create them in the first
> place?

BSD may have created them. Or evil sysadmin (me) might have created
them with hex editor.

AFAICT we seem to have the Solaris behavior (current directory):

pavel@amd:/mnt/foo$ ls -al link2/
total 3
drwxr-xr-x 2 pavel pavel 1024 May 26 11:34 .
drwxr-xr-x 4 pavel pavel 1024 May 26 11:29 ..
-rw-r--r-- 1 pavel pavel    5 May 26 11:29 file1
lrwxrwxrwx 1 pavel pavel    5 May 26 11:29 link1 -> file1
lrwxrwxrwx 1 pavel pavel   21 May 26 11:34 link2 -> 
lrwxrwxrwx 1 pavel pavel    5 May 26 11:29 this_will_be_null_link ->
file1
pavel@amd:/mnt/foo$ cd link2/
pavel@amd:/mnt/foo/link2$ ls -al
total 3
drwxr-xr-x 2 pavel pavel 1024 May 26 11:34 .
drwxr-xr-x 4 pavel pavel 1024 May 26 11:29 ..
-rw-r--r-- 1 pavel pavel    5 May 26 11:29 file1
lrwxrwxrwx 1 pavel pavel    5 May 26 11:29 link1 -> file1
lrwxrwxrwx 1 pavel pavel   21 May 26 11:34 link2 -> 
lrwxrwxrwx 1 pavel pavel    5 May 26 11:29 this_will_be_null_link ->
file1
pavel@amd:/mnt/foo/link2$ cd link2/
pavel@amd:/mnt/foo/link2/link2$ ls 
file1  link1  link2  this_will_be_null_link
pavel@amd:/mnt/foo/link2/link2$ cd ..

They are _not_ detected as broken during runtime (ext2 fs is not marked as
containing errors) but fsck seems to handle them correctly.

pavel@amd:~/misc$ /sbin/fsck.ext2 -f delme2.fs 
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Symlink /foo/link2 (inode #7717) is invalid.
Clear<y>? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

delme2.fs: ***** FILE SYSTEM WAS MODIFIED *****
delme2.fs: 15/25064 files (0.0% non-contiguous), 4724/100000 blocks
pavel@amd:~/misc$ 

I was looking for nice kernel crash but alas, nothing :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html