| Message ID | 94a3f8a3-5c0e-9fa5-ce2c-3f7e4b097a97@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | getcwd.3: Mention that "(unreachable)" is no longer returned for glibc > 2.27. | expand |
Hello Carlos, On 02/05/2018 09:34 PM, Carlos O'Donell wrote: > Michael, > > 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 > a2ac97c78bf05a55f8f616fc39a4724372dcfa95, 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. Thanks. Patch applied. Cheers, Michael > Signed-off-by: Carlos O'Donell <carlos@redhat.com> > > diff --git a/man3/getcwd.3 b/man3/getcwd.3 > index ff953a7d0..3c41736c9 100644 > --- a/man3/getcwd.3 > +++ b/man3/getcwd.3 > @@ -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. > --- >
diff --git a/man3/getcwd.3 b/man3/getcwd.3 index ff953a7d0..3c41736c9 100644 --- a/man3/getcwd.3 +++ b/man3/getcwd.3 @@ -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.
Michael, 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 a2ac97c78bf05a55f8f616fc39a4724372dcfa95, 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> ---