mirror of https://github.com/mkerrisk/man-pages
4c313d979d
From email with Christian Brauner: >>>>>> int fd_tree = open_tree(-EBADF, source, >>>>>> OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC | >>>>>> AT_EMPTY_PATH | (recursive ? AT_RECURSIVE : 0)); >>>>> >>>>> ??? >>>>> What is the significance of -EBADF here? As far as I can tell, it >>>>> is not meaningful to open_tree()? >>>> >>>> I always pass -EBADF for similar reasons to [2]. Feel free to just use -1. >>> >>> ???? >>> But here, both -EBADF and -1 seem to be wrong. This argument >>> is a dirfd, and so should either be a file descriptor or the >>> value AT_FDCWD, right? >> >> [1]: In this code "source" is expected to be absolute. If it's not >> absolute we should fail. This can be achieved by passing -1/-EBADF, >> afaict. > > D'oh! Okay. I hadn't considered that use case for an invalid dirfd. > (And now I've done some adjustments to openat(2),which contains a > rationale for the *at() functions.) > > So, now I understand your purpose, but still the code is obscure, > since > > * You use a magic value (-EBADF) rather than (say) -1. > * There's no explanation (comment about) of the fact that you want > to prevent relative pathnames. > > So, I've changed the code to use -1, not -EBADF, and I've added some > comments to explain that the intent is to prevent relative pathnames. > Okay? Sounds good. > > But, there is still the meta question: what's the problem with using > a relative pathname? Nothing per se. Ok, you asked so it's your fault: When writing programs I like to never use relative paths with AT_FDCWD because. Because making assumptions about the current working directory of the calling process is just too easy to get wrong; especially when pivot_root() or chroot() are in play. My absolut preference (joke intended) is to open a well-known starting point with an absolute path to get a dirfd and then scope all future operations beneath that dirfd. This already works with old-style openat() and _very_ cautious programming but openat2() and its resolve-flag space have made this **chef's kiss**. If I can't operate based on a well-known dirfd I use absolute paths with a -EBADF dirfd passed to *at() functions. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com> |
||
|---|---|---|
| man1 | ||
| man2 | ||
| man3 | ||
| man4 | ||
| man5 | ||
| man6 | ||
| man7 | ||
| man8 | ||
| scripts | ||
| .gitignore | ||
| CONTRIBUTING | ||
| Changes | ||
| Changes.old | ||
| MAINTAINER_NOTES | ||
| Makefile | ||
| README | ||
| man-pages-5.13.Announce | ||
| man-pages-5.13.lsm | ||
README
This package contains Linux man pages for sections 1 through 8. Some more information is given in the 'man-pages-x.y.Announce' file. Homepage ======== For information about the Linux man-pages project, see http://www.kernel.org/doc/man-pages/index.html. Bug reports and contributing ============================ If you have corrections and additions to suggest, see http://www.kernel.org/doc/man-pages/contributing.html (Although there is a mirror of this repository on GitHub, please don't report issues via the GitHub issue tracker!) For further information on contributing, see the CONTRIBUTING file. Installing and uninstalling =========================== "make install" will copy these man pages to /usr/local/share/man/man[1-8]. To install to a path different from /usr/local, use "make install prefix=/install/path". "make remove" or "make uninstall" will remove any man page in this distribution from its destination. Use with caution, and remember to use "prefix" if desired, as with the "install" target. To install only a specific man section (mandir) such as man3, use "make install-man3". Similar syntax can be used to uninstall a specific man section, such as man7: "make uninstall-man7". "make" or "make all" will perform "make uninstall" followed by "make install". Consider using multiple threads (at least 2) when installing these man pages, as the Makefile is optimized for multiple threads: "make -j install". Copyrights ========== See the 'man-pages-x.y.Announce' file.