On 11/12/20 12:24 AM, Jan Schaumann wrote: > When running 'ls -l' on a directory that the user does > not have execute permissions on, ls(1) still attempts > to generate the long listing and prints the various > fields with garbage: > > $ mkdir dir > $ touch dir/file > $ chmod a-x dir > $ ls -ld dir > drw-r--r-- 2 jschauma users 28 Nov 11 23:15 dir > $ ls -la dir > ls: cannot access dir/.: Permission denied > ls: cannot access dir/..: Permission denied > ls: cannot access dir/file: Permission denied > total 0 > d????????? ? ? ? ? ? . > d????????? ? ? ? ? ? .. > -????????? ? ? ? ? ? file > $ > > > Expected output: > > $ ls -la dir > ls: cannot access dir/.: Permission denied > ls: cannot access dir/..: Permission denied > ls: cannot access dir/file: Permission denied > $ > > This is coreutils-8.32.
That feature seems to have been turned on explicitly in version 6.0 (in 2006): https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=ccb1883fcd2 [...] Apply the stat-failed parts of Red Hat's coreutils-selinux.patch. From Ulrich Drepper. This makes it so files not mentioned on the command line (e.g., names read from a directory that *is* mentioned on the command line) for which stat fails are still listed. [...] Have a nice day, Berny
