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
