DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52VIRtZB1868852
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 52VIRtZB1868852
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=evQbCNiW
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 6FB4C385695B
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743445674;
	bh=7hnn0JJtyHcBQvTwCQJrkjLi4Nagc6MWE90IC0L1Ick=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=evQbCNiWwj12NqT/aJ4ztQ2nzrna77z71K8Jj5Ht8LoIgDWBI3JMIBLOcPQjWJbL8
	lLk5ISW0mbuEwNI/BI3YtNa/4yPzFxUPe2gx6LgQe6d/lqjkVsiDVVTBSH+azrJMiD
	zvwvlgfaYUjW93dAaa/rYND71jadgQsmHvZhe3UA=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 1A254385695B
Date:	Mon, 31 Mar 2025 20:26:30 +0200
To:	Paul Eggert <eggert AT cs DOT ucla DOT edu>
Subject:	Re: symbolic link curiousity in 3.6.0
Message-ID:	<Z-reVvpUB2n8pG-2@calimero.vinschen.de>
Mail-Followup-To:	Paul Eggert <eggert AT cs DOT ucla DOT edu>,
	=?utf-8?Q?P=C3=A1draig?= Brady <P AT draigbrady DOT com>,
	Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com,
	bug-gnulib AT gnu DOT org, Coreutils <coreutils AT gnu DOT org>
References:	<Z-aP1jhjXTUVvP-E AT calimero DOT vinschen DOT de> <11037686 DOT 3WhfQktd6Z AT nimes>
	<91c9d441-36e3-4dd5-b2ca-3cfd498d2260 AT draigBrady DOT com>
	<Z-fLulclFs13NfAm AT calimero DOT vinschen DOT de>
	<a78f800c-0463-4efb-b431-c2c244bd13c7 AT cs DOT ucla DOT edu>
	<Z-k-ALeeYtJx7SqL AT calimero DOT vinschen DOT de>
	<1c0fb53a-2a6d-4d9d-8dbe-d70cc9296d5d AT draigBrady DOT com>
	<37f0f8b7-4251-4acd-b448-2f0d7c30a988 AT cs DOT ucla DOT edu>
	<cf5a19db-0985-4f0c-887a-5eb0f7a126b4 AT draigBrady DOT com>
	<675dac19-3c71-436f-93ce-e8f73b65b16c AT cs DOT ucla DOT edu>
MIME-Version:	1.0
In-Reply-To:	<675dac19-3c71-436f-93ce-e8f73b65b16c@cs.ucla.edu>
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>,
	=?utf-8?Q?P=C3=A1draig?= Brady <P AT draigbrady DOT com>,
	Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com, bug-gnulib AT gnu DOT org,
	Coreutils <coreutils AT gnu DOT org>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 52VIRtZB1868852

On Mar 31 12:12, Paul Eggert via Cygwin wrote:
> On 3/31/25 11:27, Pádraig Brady wrote:
> > The file could be deleted at any time.
> > We're just suppressing errors in the edge case it's deleted
> 
> More generally, though, the file could be renamed and another put in its
> place, which means that an attacker could cause 'ls' to generate a line that
> does not correspond to any state of any file.
> 
> For this sort of attack an O_PATH solution is the only defense I can think
> of (for systems with O_PATH and /proc/self/fd; I don't know of solutions
> elsewhere.) And if we use O_PATH for this, we've solved the problem for the
> file-being-deleted case too.

I see what you're up to, but is that really an issue?

ls(1) always potentially shows a past state anyway.  The user can
*never* rely on the fact that the files it just printed out still exist
in the same state  or at all after ls finished.  And the worst case
which might happen in terms of the problem at hand is that ls -l doesn't
print the '+' after the permission bits.


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -