CRTL BUG: readlink succeeds on non-link

[Craig A Berry]

It's nice that VMS v8.3 includes symbolic link support. It will be even nicer when this support is completed and complies with the standard, which, at:

http://www.opengroup.org/onlinepubs/000095399/functions/readlink.html

says that readlink will fail and set errno to EINVAL when, "The path argument names a file that is not a symbolic link." On OpenVMS Alpha v8.3 with VMS83A_ACRTL V2.0 applied, calling readlink with the name of an ordinary file (not a link) succeeds and returns the contents of the file. Ouch. This means that if I have an ordinary file whose name is "foo.tmp" and whose contents are, say, "/sys$common/sysexe/dcl.exe" and I pass "foo.tmp" to readlink and call unlink with the result, I've just tried to delete a file that I (hopefully) don't have delete access to. That's an unlikely but possible scenario, but it is commonplace to call readlink in a loop where you only stop when you hit EINVAL indicating you've arrived at the target file that is not a symbolic link.

The attached file provides a simple reproducer. It just demonstrates the problem with safe temporary files and doesn't try to do anything evil.

The obvious workaround is to create a wrapper around readlink that does the check readlink fails to do; something like:

if (!lstat(filename, &st) && !S_ISLNK(st.st_mode)) {
errno = EINVAL;
return -1;
}

... now call decc$readlink

On a related matter, the standard also says that symlink will fail with ENOENT when passed a zero-length string as the name of the symbolic link. The VMS implementation instead successfully creates a link file with a bogus name (".;1").

Someone needs to actually *read* the standards and write automated tests to verify they are followed (preferably before writing the code to be tested). As far as I can see, most of the heavy lifting on symlinks was done in RMS, so the CRTL bit shouldn't have been too bad, particularly with HP-UX and Tru64 sources to lean on.

[Hein van den Heuvel]

fwiw, symlinks kinda a 'first stab' under 8.3
Andy Goldstein did a presentation at the OpenVMS Bootcamp in May 2008 about much more complete support for both symlinks and Unix compatible file naming in OpenVMS 8.next (expected to be 8.4). This may or might not change the reported problem.
This was all implemented under a Unix Portability (UP) effort. You be able to do

. cc â ^UP^a/hello.câ /obj=â ^UP^a/hello.objâ
. TYPE /SYS$LOGIN/login.com
. CREATE/SYMLINK=â ../test2â link_to_test2
. Specify explicitly whether to operate on a link or its target with /SYMLINK=[NO]TARGET
. 'mount' a directory: $ mnt dkb100:[newtest] /mnt/dkb100
. ...


Cheers,
Hein.

[Derek Garson]

>The VMS implementation instead successfully creates a link file with a bogus name (".;1").

That's not a bogus name. It's a perfectly legitimate file name, type and version. However I'll take your word for it that this does not comply with the standard.

[Craig A Berry]

Hein wrote:
------
Andy Goldstein did a presentation at the OpenVMS Bootcamp in May 2008 about much more complete support for both symlinks and Unix compatible file naming in OpenVMS 8.next (expected to be 8.4). This may or might not change the reported problem.
------

Good to hear there is more on the way.

Derek wrote:
------
>The VMS implementation instead successfully creates a link file with a bogus name (".;1").

That's not a bogus name. It's a perfectly legitimate file name, type and version. However I'll take your word for it that this does not comply with the standard.
------

Right. It's not bogus from the point of view of RMS, but it is bogus from the point of view of what symlink is supposed to do with it (it's not supposed to allow a link name with zero length). When writing code to comply with any well-defined requirements (not just standards) the characteristics of failure are just as important as the characteristics of success, but I'm sure I'm preaching to the choir on that one.