> If O_NOFOLLOW is not provided by the system, the open() call can
> follow a symbolic link which could be (depending on the circumstances)
> insecure. See the "Security Considerations" chapter of the findutils
> 4.2.x Texinfo documentation for a detailed explanation as to why.
>
> If O_NOFOLLOW isn't available, an implementation should probably use
> lstat() to double-check that it has ended up in the subdirectory it
> expected to.
I agree - Jim's initial implementation just does a plain chdir() if O_NOFOLLOW
is zero (or missing), but a safer approach on systems with fchdir() would
be a fallback path of lstat(), open(), fstat(), check that st_ino is
unchanged, fchdir(), close(). On systems without fchdir(), you are stuck
with lstat(), chdir(), lstat("."), check that st_ino is unchanged. (The fchdir
solution is nicer, because you don't have to worry about chdir() back to
the original location on failure.) This should probably be added to the
chdir_no_follow() implementation, so that it lives up to its name.
>
> An additional wrinkle is that at compile time O_NOFOLLOW may be
> provided, but the resulting binary might be run on a system lacking
> support for O_NOFOLLOW. While one might ordinarily just dismiss this
> by saying "well, that's not the recommended way to do things" this
> issue is security-related, so we should be cautious. Findutils (in
> 4.2.x, before the switch to fts()) uses the following check:
How likely is it that someone configures on a system with O_NOFOLLOW,
but intends to run the binary on a system that does not honor it? If
it is a likely problem, then your code should probably be added in to
the fchdir_new implementation.
--
Eric Blake
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
