Add O_SYMLINK emulation and freadlink(3)

[kib]

Summary

Add O_SYMLINK emulation

for MacOSX partial compatibility, defined as O_PATH | O_NOFOLLOW.
fstat(2) and freadlink(3) works on the resulting file descriptors,
but reads on the regular file do not.

More complete but more hackish version was developed but deemed too
hackish.


libc: add freadlink(3)

[kib]

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

[markj]

In D56365#1289902, @kib wrote:

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

I cannot find much documentation for O_SYMLINK, it is not clear to me if open(<regular file>, O_SYMLINK) is permitted at all, and I have no good way to test. I would prefer O_PATH | O_NOFOLLOW too.

lib/libc/gen/freadlink.c

6

I think this line is not supposed to be added anymore.

lib/libthr/thread/thr_syscalls.c

301 ↗

(On Diff #175346)

This is assuming O_SYMLINK is never ORed with other flags (except O_RDONLY I suppose).

sys/sys/fcntl.h

149

183

O_SYNC == O_FSYNC

[kib]

In D56365#1291389, @markj wrote:

In D56365#1289902, @kib wrote:

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

I cannot find much documentation for O_SYMLINK, it is not clear to me if open(<regular file>, O_SYMLINK) is permitted at all, and I have no good way to test. I would prefer O_PATH | O_NOFOLLOW too.

I read it in the following paragraph from MacOSX open(2) man page:

If O_SYMLINK is used in the mask and the target file passed to open() is a symbolic link then the open()
will be for the symbolic link itself, not what it links to.

For now I left the libc hack in the branch, but lets wait for des@ opinion.

lib/libthr/thread/thr_syscalls.c

301 ↗

(On Diff #175346)

Why not? I masking the O_SYMLINK bits when testing.

The problematic case is when consumer specifies all the constituent bits from O_SYMLINK for open(), but the combination of O_PATH | O_DSYNC does not make sense already.

[kib]

Minor editings.

[markj]

In D56365#1291416, @kib wrote:

In D56365#1291389, @markj wrote:

In D56365#1289902, @kib wrote:

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

I cannot find much documentation for O_SYMLINK, it is not clear to me if open(<regular file>, O_SYMLINK) is permitted at all, and I have no good way to test. I would prefer O_PATH | O_NOFOLLOW too.

I read it in the following paragraph from MacOSX open(2) man page:

If O_SYMLINK is used in the mask and the target file passed to open() is a symbolic link then the open()
will be for the symbolic link itself, not what it links to.

For now I left the libc hack in the branch, but lets wait for des@ opinion.

Right, this is all I found too.

lib/libthr/thread/thr_syscalls.c

301 ↗

(On Diff #175346)

Sorry, I misread.

[kib]

sys/sys/fcntl.h

186

markj@, are you fine with this chunk? I might push it in advance.

[markj]

sys/sys/fcntl.h

186

Yes, I think it's fine.

[kib]

Rebase after partial commit.

[kevans]

In D56365#1289902, @kib wrote:

An alternative for this O_SYMLINK is to define it just to O_PATH | O_NOFOLLOW, if it is not important to be able to open(<regular file>, O_SYMLINK | O_RDONLY) and be able to read from the resulting fd.
I would prefer that implementation instead of the reopening with EMPTYPATH for non-symlinks, but I do not know real-world usage patterns for O_SYMLINK.

It's hard to say... based on inspecting various uses, it seems like it's /usually/ expected to be used for things like applying acls/xattrs to the result, at least. read(2) from it does work if it's a regular file, though.

lib/libc/sys/openat.c

83 ↗

(On Diff #175628)

XNU technically allows this, they have a test in xnu that exercises it, apparently because someone noticed that it was ignored with O_CREAT: https://github.com/apple-oss-distributions/xnu/blob/main/tests/vfs/open_symlink.c

[kib]

Retract ambitions of O_SYMLINK to O_PATH | O_NOFOLLOW.