musl/src/misc/realpath.c, branch master musl - an implementation of the standard library for Linux-based systems implement realpath directly instead of using procfs readlink 2020年11月30日T18:46:52+00:00 Rich Felker dalias@aerifal.cx 2020年11月30日T17:14:47+00:00 29ff7599a448232f2527841c2362643d246cee36 inability to use realpath in chroot/container without procfs access and at early boot prior to mount of /proc has been an ongoing issue, and it turns out realpath was one of the last remaining interfaces that needed procfs for its core functionality. during investigation while reimplementing, it was determined that there were also serious problems with the procfs-based implementation. most seriously it was unsafe on pre-O_PATH kernels, and unlike other places where O_PATH was used, the unsafety was hard or impossible to fix because O_NOFOLLOW can't be used (since the whole purpose was to follow symlinks). the new implementation is a direct one, performing readlink on each path component to resolve it. an explicit stack, as opposed to recursion, is used to represent the remaining components to be processed. the stack starts out holding just the input string, and reading a link pushes the link contents onto the stack. unlike many other implementations, this one does not call getcwd initially for relative pathnames. instead it accumulates initial .. components to be applied to the working directory if the result is still a relative path. this avoids calling getcwd (which may fail) at all when symlink traversal will eventually yield an absolute path. it also doesn't use any form of stat operation; instead it arranges for readlink to tell it when a non-directory is used in a context where a directory is needed. this minimizes the number of syscalls needed, avoids accessing inodes when the directory table suffices, and reduces the amount of code pulled in for static linking.
inability to use realpath in chroot/container without procfs access
and at early boot prior to mount of /proc has been an ongoing issue,
and it turns out realpath was one of the last remaining interfaces
that needed procfs for its core functionality. during investigation
while reimplementing, it was determined that there were also serious
problems with the procfs-based implementation. most seriously it was
unsafe on pre-O_PATH kernels, and unlike other places where O_PATH was
used, the unsafety was hard or impossible to fix because O_NOFOLLOW
can't be used (since the whole purpose was to follow symlinks).
the new implementation is a direct one, performing readlink on each
path component to resolve it. an explicit stack, as opposed to
recursion, is used to represent the remaining components to be
processed. the stack starts out holding just the input string, and
reading a link pushes the link contents onto the stack.
unlike many other implementations, this one does not call getcwd
initially for relative pathnames. instead it accumulates initial ..
components to be applied to the working directory if the result is
still a relative path. this avoids calling getcwd (which may fail) at
all when symlink traversal will eventually yield an absolute path. it
also doesn't use any form of stat operation; instead it arranges for
readlink to tell it when a non-directory is used in a context where a
directory is needed. this minimizes the number of syscalls needed,
avoids accessing inodes when the directory table suffices, and reduces
the amount of code pulled in for static linking.
move and deduplicate declarations of __procfdname to make it checkable 2018年09月12日T18:34:27+00:00 Rich Felker dalias@aerifal.cx 2018年09月06日T17:39:08+00:00 6fcd60ddd903df13402704fe6026cb1f8e780fd7 syscall.h was chosen as the header to declare it, since its intended usage is alongside syscalls as a fallback for operations the direct syscall does not support.
syscall.h was chosen as the header to declare it, since its intended
usage is alongside syscalls as a fallback for operations the direct
syscall does not support.
support kernels with no SYS_open syscall, only SYS_openat 2014年05月25日T02:54:05+00:00 Rich Felker dalias@aerifal.cx 2014年05月25日T02:54:05+00:00 594c827a22124ae550b9a877b8188e0898dff8db open is handled specially because it is used from so many places, in so many variants (2 or 3 arguments, setting errno or not, and cancellable or not). trying to do it as a function would not only increase bloat, but would also risk subtle breakage. this is the first step towards supporting "new" archs where linux lacks "old" syscalls.
open is handled specially because it is used from so many places, in
so many variants (2 or 3 arguments, setting errno or not, and
cancellable or not). trying to do it as a function would not only
increase bloat, but would also risk subtle breakage.
this is the first step towards supporting "new" archs where linux
lacks "old" syscalls.
remove incorrect cancellation points from realpath 2013年08月31日T20:01:01+00:00 Rich Felker dalias@aerifal.cx 2013年08月31日T20:01:01+00:00 35e8621a28db1c34685adbbf1c2229270cbf7236
debloat realpath's allocation strategy 2013年08月31日T19:50:23+00:00 Rich Felker dalias@aerifal.cx 2013年08月31日T19:50:23+00:00 dfddd43256f7ad4bad991eeff5cc51772595f327 rather than allocating a PATH_MAX-sized buffer when the caller does not provide an output buffer, work first with a PATH_MAX-sized temp buffer with automatic storage, and either copy it to the caller's buffer or strdup it on success. this not only avoids massive memory waste, but also avoids pulling in free (and thus the full malloc implementation) unnecessarily in static programs.
rather than allocating a PATH_MAX-sized buffer when the caller does
not provide an output buffer, work first with a PATH_MAX-sized temp
buffer with automatic storage, and either copy it to the caller's
buffer or strdup it on success. this not only avoids massive memory
waste, but also avoids pulling in free (and thus the full malloc
implementation) unnecessarily in static programs.
make realpath use O_PATH when opening the file 2013年08月31日T19:44:58+00:00 Rich Felker dalias@aerifal.cx 2013年08月31日T19:44:58+00:00 27b4923ba00f0a7511c7ebf5f19313d6313052e9 this avoids failure if the file is not readable and avoids odd behavior for device nodes, etc. on old kernels that lack O_PATH, the old behavior (O_RDONLY) will naturally happen as the fallback.
this avoids failure if the file is not readable and avoids odd
behavior for device nodes, etc. on old kernels that lack O_PATH, the
old behavior (O_RDONLY) will naturally happen as the fallback.
debloat code that depends on /proc/self/fd/%d with shared function 2013年08月02日T16:59:45+00:00 Rich Felker dalias@aerifal.cx 2013年08月02日T16:59:45+00:00 c8c0844f7fbcb955848ca84432e5ffcf71f1cef1 I intend to add more Linux workarounds that depend on using these pathnames, and some of them will be in "syscall" functions that, from an anti-bloat standpoint, should not depend on the whole snprintf framework.
I intend to add more Linux workarounds that depend on using these
pathnames, and some of them will be in "syscall" functions that, from
an anti-bloat standpoint, should not depend on the whole snprintf
framework.
fix some more O_CLOEXEC/SOCK_CLOEXEC issues 2012年09月29日T21:59:50+00:00 Rich Felker dalias@aerifal.cx 2012年09月29日T21:59:50+00:00 f2d08cf7558176af7ef36cf5b5213e676b02d7ac
use restrict everywhere it's required by c99 and/or posix 2008 2012年09月07日T02:44:55+00:00 Rich Felker dalias@aerifal.cx 2012年09月07日T02:44:55+00:00 400c5e5c8307a2ebe44ef1f203f5a15669f20347 to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
fix memory leak on failure in realpath 2011年06月18日T11:41:14+00:00 Rich Felker dalias@aerifal.cx 2011年06月18日T11:41:14+00:00 d43ff110bcb258df61448d21da3b1a89088388f6

AltStyle によって変換されたページ (->オリジナル) /