Date: Tue, 8 Sep 2020 13:19:04 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: realpath without procfs Since it was raised yet again on #musl, I took some time to research justification for, and ease of implementing, realpath without procfs. It turns out that, while musl documents needing procfs and allows that arbitrary amounts of stuff may be broken if it's not available, realpath is the main function where the core functionality disappears without procfs. Other things are mostly lesser: - handling of O_SEARCH/O_EXEC fds in some of the f* functions where kernel gives EBADF for O_PATH fds (nothing uses these anyway). - implementing fchmodat with AT_SYMLINK_NOFOLLOW (important but will eventually have a non-hack way to do it via a new syscall). - ttyname (important to things that use it) - pthread_setname_np (nonstandard and non-load-bearing) - dynamic linker identifying executable pathname This is actually a lot less than I expected, and makes it reasonable to envision a path to eventually not needing procfs at all. So, I did the work to figure out what would be needed to write a procfs-free realpath, and it turns out that actually writing it was not any harder, so I did. Attached is a draft. It needs testing, and I'm undecided whether we should keep the old code and just use this as a fallback, or just replace it. (The old code has fixed 5-syscall overhead and ugly side effects on kernels too old to have O_PATH; new code needs one syscall per path component and might (?) have worse or different behavior under concurrent changes to the dir tree.) Some notes: - Attempts to support all pathnames where no intermediate exceeds PATH_MAX. - Initial // is treated as special, but //. and //.. resolve to / - getcwd is expanded initially if pathname is relative. This might be a bad choice since it causes failure whenever pwd is not representable even if the symlink reached via a relative pathname would take us to an absolute path that is representable. We could accumulate a relative path, including preserving .. components, until the first absolute-target symlink, and only apply it by prepending (and cancelling ..) at the end if no absolute-target symlink was encountered, but that requires some rework to do. Thoughts? Rich View attachment "realpath2.c" of type "text/plain" (1563 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.