mirror of https://github.com/mkerrisk/man-pages
getcwd.3: Mention that "(unreachable)" is no longer returned for glibc >= 2.27.
With glibc fix 52a713fdd0a30e1bd79818e2e3c4ab44ddca1a94 for
CVE-2018-1000001 (Sourceware BZ #22679) the implementation in the
just released glibc 2.27 has been changed such that instead of
returning "(unreachable)" the implementation now returns ENOENT
as it would have if the current directory had been unlinked.
I see that in 2015 the quirk was documented in commit
a2ac97c78b
, and this is no longer
true with glibc 2.27, but may continue to be true in other C libraries,
so I reference NOTES from the paragraph in the central text.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
46dc0687e4
commit
294851f3fa
|
@ -91,7 +91,9 @@ the current directory into another mount namespace.
|
|||
When dealing with paths from untrusted sources, callers of these
|
||||
functions should consider checking whether the returned path starts
|
||||
with '/' or '(' to avoid misinterpreting an unreachable path
|
||||
as a relative path.
|
||||
as a relative path. This is no longer true under some C libraries,
|
||||
see
|
||||
.BR NOTES .
|
||||
.PP
|
||||
The
|
||||
.BR getcwd ()
|
||||
|
@ -270,6 +272,16 @@ generic implementation is called.
|
|||
Only in that case can
|
||||
these calls fail under Linux with
|
||||
.BR EACCES .
|
||||
.PP
|
||||
Since Linux commit v2.6.36 which added "(unreachable)" the glibc
|
||||
.BR getcwd ()
|
||||
has failed to conform to POSIX and returned a relative path when the API
|
||||
contract requires an absolute path. With glibc 2.27 onwards this is corrected;
|
||||
calling
|
||||
.BR getcwd ()
|
||||
from such a path will now result in failure with
|
||||
.BR ENOENT .
|
||||
|
||||
.PP
|
||||
These functions are often used to save the location of the current working
|
||||
directory for the purpose of returning to it later.
|
||||
|
|
Loading…
Reference in New Issue