Re: [bug] coreutils: potentially dangerous: $(realpath //) != /
- Date: Mon, 12 Mar 2018 20:43:13 -0500
- From: Eric Blake <eblake@xxxxxxxxxx>
- Subject: Re: [bug] coreutils: potentially dangerous: $(realpath //) != /
On 03/12/2018 06:38 PM, Mikhail Usenko via cygwin wrote:
Well, guys my expextations are that the program/script execution conditions
in Cygwin should be the same as in other popular POSIX systems
(namely it is Linux)
POSIX says that the behavior of leading // is implementation-defined
(that is, an implementation MUST document somewhere what it means).
4.13 Pathname Resolution
"A pathname consisting of a single <slash> shall resolve to the root
directory of the process. A null pathname shall not be successfully
resolved. If a pathname begins with two successive <slash> characters,
the first component following the leading <slash> characters may be
interpreted in an implementation-defined manner, although more than two
leading <slash> characters shall be treated as a single <slash> character."
Just because Linux has taken the stance that their documented definition
of // is "synonym for /" does NOT mean that ALL POSIX systems have taken
the same approach; Cygwin has taken the approach that "// is documented
to be the root of network access points, distinct from /".
POSIX allows leeway between implementations; this is one of those
documented places where they differ, yet are still both POSIX compliant
with their different choices. If your script is not robust to what
POSIX has already warned you about, fix your script.
and, as a consequence, I should avoid the case where
somewhere in a bash script evaluating of some variable would lead to one of
the following command to execute:
rm -rf /*
rm -rf //*
rm -rf ///*
rm -rf ////*
that all do the very same thing in Linux.
3 of the 4 do the same thing on ALL POSIX platforms. The only one that
has implementation-defined behavior is 'rm -rf //*', which is different
on systems where // is distinct (such as Cygwin). All the other
spellings (attempt) to remove all non-hidden files from the root directory.
Furthermore, you need to realize that GNU coreutils 'rm' already has
special logic (permitted by POSIX) such that 'rm -rf /' fails unless you
use --no-preserve-root ('rm -rf /*' unfortunately does not trigger the
special logic, only an attempt to directly remove the root directory is
flagged - but you're also forgetting that /* does not necessarily list
all files under /, thanks to hidden files, and that 'rm -rf "$dir"' is
always better than 'rm -rf "$dir"/*' if you are worried about hidden
files in $dir and/or command-line length limits due to the glob
expansion of *). And coreutils, as packaged for Cygwin, has been
patched to extend the special root-recognition logic for / to ALSO
recognize // as a case where recursive removal should fail without
--no-preserve-root (again, only when spelled 'rm -rf //', not 'rm -rf //*').
If at some time it was considered that
$ ls //Server/Folder
in Cygwin should behave like
net view \\Server\Folder
in Windows to be able to view network shares,
Yes, that's what Cygwin's // is documented to behave like.
I belive this could be realized
with using of some special folder e.g. /cygnetwork, like /cygdrive does it for
Patches are considered, but for now, we aren't going to change behavior
without a concrete implementation of an alternative behavior. And
changing it now (instead of 15 or so years ago, when Cygwin // was first
given its current behavior) would likely break existing users that
expect the current behavior. So feel free to write a patch, but it may
be an uphill battle to prove it has merit.
Supporting of UNC paths that are actually off the POSIX unified tree, directly
for POSIX user commands, breaks consistency with Linux user environment, which
is the feature of Cygwin that is highly valued by the most of the users.
Use of // in Linux is already on shaky ground, given that POSIX has
already declared it to be implementation-defined. Any implementation is
also free to define // as an error that never resolves to a path; such
an implementation would still comply with POSIX, but break expectations
of scripts that are written to cater to only the Linux and Cygwin behaviors.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple