This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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).

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html 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
Windows drives.

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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]