DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52VIRtZB1868852
Date: Mon, 31 Mar 2025 20:26:30 +0200
To: Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: symbolic link curiousity in 3.6.0
Message-ID: <Z-reVvpUB2n8pG-2@calimero.vinschen.de>
Mail-Followup-To: Paul Eggert <eggert@cs.ucla.edu>,
 =?utf-8?Q?P=C3=A1draig?= Brady <P@draigbrady.com>,
 Bruno Haible <bruno@clisp.org>, cygwin@cygwin.com,
 bug-gnulib@gnu.org, Coreutils <coreutils@gnu.org>
References: <Z-aP1jhjXTUVvP-E@calimero.vinschen.de> <11037686.3WhfQktd6Z@nimes>
 <91c9d441-36e3-4dd5-b2ca-3cfd498d2260@draigBrady.com>
 <Z-fLulclFs13NfAm@calimero.vinschen.de>
 <a78f800c-0463-4efb-b431-c2c244bd13c7@cs.ucla.edu>
 <Z-k-ALeeYtJx7SqL@calimero.vinschen.de>
 <1c0fb53a-2a6d-4d9d-8dbe-d70cc9296d5d@draigBrady.com>
 <37f0f8b7-4251-4acd-b448-2f0d7c30a988@cs.ucla.edu>
 <cf5a19db-0985-4f0c-887a-5eb0f7a126b4@draigBrady.com>
 <675dac19-3c71-436f-93ce-e8f73b65b16c@cs.ucla.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <675dac19-3c71-436f-93ce-e8f73b65b16c@cs.ucla.edu>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>,
        =?utf-8?Q?P=C3=A1draig?= Brady <P@draigbrady.com>,
        Bruno Haible <bruno@clisp.org>, cygwin@cygwin.com, bug-gnulib@gnu.org,
        Coreutils <coreutils@gnu.org>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

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