[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200908171901.GV3265@brightrain.aerifal.cx>
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.
