X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=QV/sT8/ty86GYL+o
	K0bo4W8gI4XfsWkiCQKmrx3lBfQMno1i5P2RdT2t5sfj8NzJxCEr37PnMFOeQj3Z
	pnv74PFLNJHqgz+eG0r/K0ZbcDNNH7iQJ5NRocgxht+i8ivlgMxaRhDNPh0RtRsx
	Cj2QtIGWFPIju3iak9SVSYNkink=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=k3Bux1AsGkeCfQmOQcfqrm
	k31Y8=; b=mMBeC/FI2UeYu9x/VZqfLpDLfqEqLsKrtO5vLgv8kpx75hLxp7WS5Q
	ci03AsSJXcQ5Wg5dswfFvAwLpGiF2NxMiRVqwmmx+P6Hn3OjLT4Jf1c8kgn5iCkT
	jXBC70llaBYGZHmTbtVKArjxVoOxCU8bKEWySsD1JNVnDG8rD8Jpk=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=ALSO, MUST, battle, successive
X-HELO:	mx1.redhat.com
Subject:	Re: [bug] coreutils: potentially dangerous: $(realpath //) != /
To:	cygwin AT cygwin DOT com, cygwin AT inbox DOT ru
References:	<20180312232815 DOT 692b5da79fc18abf86d42ba1 AT inbox DOT ru> <20180313023854 DOT 2e07e4396f934961935e4435 AT inbox DOT ru>
From:	Eric Blake <eblake AT redhat DOT com>
Message-ID:	<0277f5b4-35e4-4da0-2bea-b73c4fdcfa89@redhat.com>
Date:	Mon, 12 Mar 2018 20:43:13 -0500
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version:	1.0
In-Reply-To:	<20180313023854.2e07e4396f934961935e4435@inbox.ru>
X-IsSubscribed:	yes

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

- Raw text -