|author||Rich Felker <firstname.lastname@example.org>||2013-08-02 12:25:32 -0400|
|committer||Rich Felker <email@example.com>||2013-08-02 12:25:32 -0400|
work around linux's lack of flags argument to fchmodat syscall
previously, the AT_SYMLINK_NOFOLLOW flag was ignored, giving dangerously incorrect behavior -- the target of the symlink had its modes changed to the modes (usually 0777) intended for the symlink). this issue was amplified by the fact that musl provides lchmod, as a wrapper for fchmodat, which some archival programs take as a sign that symlink modes are supported and thus attempt to use. emulating AT_SYMLINK_NOFOLLOW was a difficult problem, and I originally believed it could not be solved, at least not without depending on kernels newer than 3.5.x or so where O_PATH works halfway well. however, it turns out that accessing O_PATH file descriptors via their pseudo-symlink entries in /proc/self/fd works much better than trying to use the fd directly, and works even on older kernels. moreover, the kernel has permanently pegged these references to the inode obtained by the O_PATH open, so there should not be race conditions with the file being moved, deleted, replaced, etc.
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions