public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/14578] fchmodat(..., AT_SYMLINK_NOFOLLOW) returns ENOTSUP on non-symlinks Date: Tue, 30 Jul 2013 16:16:00 -0000 [thread overview] Message-ID: <bug-14578-131-LrnmYl21vV@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-14578-131@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=14578 --- Comment #8 from Rich Felker <bugdal at aerifal dot cx> --- On modern Linux (just tested on 3.10.4), the following solution works with no race condition: 1. Check fstatat, fail if symlink. 2. Use openat with O_PATH|O_NOFOLLOW. 3. Use fstat on the resulting fd, fail if symlink. 4. Use fchmod on the resulting fd. Step 1 is not strictly necessary, but it's nice to definitively fail on symlinks that aren't racing, whereas the subsequent tests could fail spuriously on hitting the open file limit, etc. There are however failure cases that need to be considered: Step 2 can act as a plain O_RDONLY open if O_PATH is not available on the kernel in use. I believe this can be tested for by attempting to open /dev/null with O_PATH and trying to write to the resulting file descriptor. If it succeeds, the kernel lacks O_PATH. Note that, aside from the nasty case of opening a device file and having it do something when you open it, plain O_RDONLY would do just fine and would make this workaround work even on ancient kernels, BUT it will spuriously fail if the file is mode 000 and the caller is not root. Also, if O_PATH is not supported, O_NOFOLLOW will cause ELOOP if the target is a symlink, instead of opening a fd to the symlink itself, which would need to be treated as an error condition. Also note that, since O_NOFOLLOW Is being used, there is no danger of following a symlink to a device file if O_PATH is not supported. The bad behavior with devices could only happen if the device name were passed directly. Step 2 can also simply fail for reasons like having too many open files. Step 3 can also fail. On a large number of kernel versions (2.6 up through 3.5 or maybe a little later), file descriptors obtained by O_PATH are not valid for passing to fstat, fchmod, etc. I do not believe there is any workaround for this case, unless you want to fall back to just using O_RDONLY. Since current Linux admits a workaround, I believe a solution based on this approach should be applied to glibc. However, some more discussion is needed to determine how to handle old kernels and errors. -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2013-07-30 16:16 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-09-13 16:42 [Bug libc/14578] New: " mgorny at gentoo dot org 2012-09-13 17:01 ` [Bug libc/14578] " joseph at codesourcery dot com 2012-09-13 17:05 ` joseph at codesourcery dot com 2012-09-13 22:40 ` bugdal at aerifal dot cx 2012-09-13 23:07 ` joseph at codesourcery dot com 2012-09-13 23:09 ` bugdal at aerifal dot cx 2012-09-13 23:17 ` bugdal at aerifal dot cx 2012-09-14 0:46 ` joseph at codesourcery dot com 2013-07-30 16:16 ` bugdal at aerifal dot cx [this message] 2013-07-30 16:53 ` bugdal at aerifal dot cx 2013-08-02 16:21 ` bugdal at aerifal dot cx 2014-06-17 4:33 ` fweimer at redhat dot com 2020-09-10 15:40 ` [Bug libc/14578] /proc-based emulation for lchmod, fchmodat bugdal at aerifal dot cx
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-14578-131-LrnmYl21vV@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).