GNU bug report logs - #13635
ls: use different color for unreadable files

Previous Next

To reply to this bug, email your comments to 13635 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Joshua Rogers <megamansec <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Strange ls bug (Combination of -a and --color)
Date: Wed, 06 Feb 2013 18:55:49 +1100

[Message part 1 (text/plain, inline)]

Hi,

I'm using 'ls' and I'm encountering a pretty strange bug.

I just rsync'd my remote server for backup, and on my local machine I
run the command 'ls -lh csf/'
Well.. Here's the result;

$ ls -lh csf/
ls: cannot access csf/.: Permission denied
ls: cannot access csf/..: Permission denied
total 0
d????????? ? ? ? ?                ? .
d????????? ? ? ? ?                ? ..


running just 'ls csf/'
$ ls csf/
ls: cannot access csf/.: Permission denied
ls: cannot access csf/..: Permission denied
.  ..


It appears to be outputting the information, even though it should be
exiting after it says permission denied.

I've tried rm -rf csf/ and re-rsyncing it, but the problem persists.


My .bashrc;
    alias ls='ls -aC --color=auto'


Running '/bin/ls csf/'
just results in a newline.

running '/bin/ls -aC' doesn't cause the error, neither does '/bin/ls -C
--color=auto csf/'
But, '/bin/ls -a --color=auto csf/' DOES.
So it seems to be the combination of --color and -a.

Thanks


-- 
*Joshua Rogers* - Retro Game Collector && IT Security Specialist
gpg pubkey <http://www.internot.info/docs/gpg_pubkey.asc.gpg>

[Message part 2 (text/html, inline)]

Message #8 received at 13635 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Joshua Rogers <megamansec <at> gmail.com>
Cc: 13635 <at> debbugs.gnu.org
Subject: Re: bug#13635: Strange ls bug (Combination of -a and --color)
Date: Wed, 6 Feb 2013 01:07:00 -0700

Joshua Rogers wrote:
> I just rsync'd my remote server for backup, and on my local machine I
> run the command 'ls -lh csf/'
> Well.. Here's the result;
> 
> $ ls -lh csf/
> ls: cannot access csf/.: Permission denied
> ls: cannot access csf/..: Permission denied
> total 0
> d????????? ? ? ? ?                ? .
> d????????? ? ? ? ?                ? ..

What is the output of (without the trailing slash and with -d):

  ls -ld csf

I suspect that you are missing the 'x' search permission bit but have
the 'r' bit.  You can read the directory but cannot search it.  To fix
this add the 'x' bit back to the directory.  If it is a directory.

  chmod a+x csf

Bob

Message #11 received at 13635 <at> debbugs.gnu.org (full text, mbox):

From: Joshua Rogers <megamansec <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 13635 <at> debbugs.gnu.org
Subject: Re: bug#13635: Strange ls bug (Combination of -a and --color)
Date: Wed, 06 Feb 2013 19:10:47 +1100

[Message part 1 (text/plain, inline)]

Hi Bob,

Here is the result of that command;

$ ls -ld csf
drw------- 2 toil toil 4096 2013-02-05 19:26 csf


The result of running it with the trailing / aswell;
$ ls -ld csf/
drw------- 2 toil toil 4096 2013-02-05 19:26 csf/


So it seems that you may be correct.
That chmod fixes the problem, But it is still a bug that it does not
exit if it does have permissions, and has color on.


Thanks
*Joshua Rogers* - Retro Game Collector && IT Security Specialist
gpg pubkey <http://www.internot.info/docs/gpg_pubkey.asc.gpg>
On 06/02/13 19:07, Bob Proulx wrote:
>   ls -ld csf

[Message part 2 (text/html, inline)]

Message #14 received at 13635 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Joshua Rogers <megamansec <at> gmail.com>
Cc: 13635 <at> debbugs.gnu.org
Subject: Re: bug#13635: Strange ls bug (Combination of -a and --color)
Date: Wed, 6 Feb 2013 01:39:56 -0700

Joshua Rogers wrote:
> $ ls -ld csf
> drw------- 2 toil toil 4096 2013-02-05 19:26 csf

Yes. :-)

> So it seems that you may be correct.
> That chmod fixes the problem,

Yes.  You said you rsync'd data from another machine.  Was the
permissions copied from the remote machine the same there?

> But it is still a bug that it does not exit if it does have
> permissions, and has color on.

Sorry but I don't understand what you are saying.  The ls command
didn't create the directory with that permission.  The ls command
simply reported it.  That isn't a bug in ls.  And I am sure not a bug
in rsync either since I am sure that rsync just copied the source
permissions directly.  I think this is all expected behavior.

If either --color or -l is specified then it will cause ls to need to
stat(2) each entry in order to get information about it.  But it can't
stat without the 'x' bit allowing it.  So it reports what it can which
is simply the file name and nothing more.  And of course the program
does exit afterward.

Using 'ls -l' reports both "." and ".." and therefore they are listed
by name but without the missing attributes.  Using 'ls' without -l
does not report "." and ".." and therefore reported nothing but a
newline.

Bob

Message #17 received at 13635 <at> debbugs.gnu.org (full text, mbox):

From: Joshua Rogers <megamansec <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 13635 <at> debbugs.gnu.org
Subject: Re: bug#13635: Strange ls bug (Combination of -a and --color)
Date: Wed, 06 Feb 2013 19:43:15 +1100

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, I understand that, but the

"

d????????? ? ? ? ?                ? .
d????????? ? ? ? ?                ? .."

That is a bug, no?


Thanks

*Joshua Rogers* - Retro Game Collector && IT Security Specialist
gpg pubkey <http://www.internot.info/docs/gpg_pubkey.asc.gpg>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJREhefAAoJEJFmX8J3Enzdx6YQALYyKJKmFjPm60FVl1coXYGo
eGMc7lKfVxnZnnsXwbimNYZqi1eoVdzX0tkCgg7oCsOdJgVPHMtaYMesJ9mPZJ2R
rGbkXSH2QIDcLvaB0/W8np+56LLw334i77GbobrpwHWxRfM9/K6tkdXWz6xRM7xm
k0gBiBm5gwNnA8dDoKN4PpKZRRSdPu8xZoEdsVq9QxOWXZ+gbAADYqzeDs56uNkB
aBConVnZjcPqcUqBVPf+j/VAP2XSiaWkoJzo35CJXV7ZWaK2g1AHBp4ONtjGIuQy
+SWPT9RssoT2NJ7t5D8u6hj2jDHQc2YDLqDfskuluu89+QEm8iHcI5cNpHDF3Qrn
8vxyqexdvUMTxz/qmi+x1XbAeEggN4gv5w545Z/w1OeEJU81sDGaq16ddHqFDQW0
gENYu4Yb2WaPwWVCoeXIMg2a9zL3LX3v08NFmol12dcbFaVGv/Caqju2Zg+Rhmrk
dlJ5doGxS7a0ZxcjFY7Yb73SNgA/aqvFAxjlmaDXmOtDIwk/vkU1LKdI1jCw60xd
BwOEjeqhKnsGaO1rkCS2Rc20+d+m16AMhRp8cxq5kFaYlQlCTM67MaD6ws7xqZs6
tzfPdwdQ61Wq7ttWU735NxUws61GF/Ci/OAnGv3eLhoKRsRXrA9ieScEWLwEJquV
Yv7gIfeVYbj7I/pecCiI
=Onq6
-----END PGP SIGNATURE-----

[Message part 2 (text/html, inline)]

Message #20 received at 13635 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Joshua Rogers <megamansec <at> gmail.com>
Cc: 13635 <at> debbugs.gnu.org
Subject: Re: bug#13635: Strange ls bug (Combination of -a and --color)
Date: Wed, 6 Feb 2013 02:01:38 -0700

Joshua Rogers wrote:
> Okay, I understand that, but the
> 
> "
> 
> d????????? ? ? ? ?                ? .
> d????????? ? ? ? ?                ? .."
> 
> That is a bug, no?

No it isn't.  Since ls didn't have permission to search the directory
it could not stat those files and therefore could not report any
information aout them.  The long format was specified using -l and
therefore the missing columns were filled in with '?'.

If the above was all there was printed then that would be a bug.  But
That wasn't all of the output.  Let me reproduce it including the
important part.

  $ ls -lh csf/
  ls: cannot access csf/.: Permission denied
  ls: cannot access csf/..: Permission denied
  total 0
  d??? ? ? ? ?                ? .
  d??? ? ? ? ?                ? ..

Specifically these lines:

  ls: cannot access csf/.: Permission denied
  ls: cannot access csf/..: Permission denied

That is an error message printed by ls that it did not have the
permission it needed.  It can read their names but it can't find any
stat information about them such as file mode, owner, group, size or
timestamp.  It printed an error message to stderr.  It then gave the
listing with the information it had available.

Also if you were to check the exit code of ls you would find that it
exited with a non-zero exit code indicating that an error occured.

  echo $?
  1

As long as that isn't asked to be printed then it is okay without
knowing those things.  But when asked with any of -l or --color or -a
then it tries to get information about those files, fails, prints the
error message, and exits non-zero.

The ls program has printed an error message where appropriate and has
exited with an error when appropriate.  I see no bug there.  Plus it
has been this way for forty years.  I wouldn't want to change this
core behavior now without a very good reason to do so.

I think the part you are having trouble with is the separation of
permission between 'r' and 'x'.  The 'r' allows reading the names of
the files.  The 'x' allows "searching" which in this case means being
able to stat(2) the file.

  man 2 stat

       These functions return information about a file.  No
       permissions are required on the file itself, but—in the case of
       stat() and lstat() — execute (search) permission is required on
       all of the directories in path that lead to the file.

And so we see that some actions need 'r' and some need 'x'.  I don't
know why the permissions were split this way.  But they were and so
they continue to be because changing long established behavior is very
disruptive.

Bob

Message #23 received at 13635 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Joshua Rogers <megamansec <at> gmail.com>
Cc: 13635 <at> debbugs.gnu.org
Subject: Re: bug#13635: Strange ls bug (Combination of -a and --color)
Date: Wed, 06 Feb 2013 15:40:53 -0800

My guess is that 'csf' is readable but not searchable.
That would explain your symptoms:

$ ls -ld csf
dr--------. 2 eggert eggert 4096 Feb  6 15:31 csf
$ ls -ld csf/.
ls: cannot access csf/.: Permission denied
$ ls --color=always -a csf
ls: cannot access csf/.: Permission denied
ls: cannot access csf/..: Permission denied
.  ..

In the last example, 'ls' needs to stat csf/. and csf/..
to see whether their permissions are weird (since directories
with weird permissions are given different colors), but
it cannot do so since csf lacks search permission.

One possible fix would be to alter 'ls' so that, if 'ls' cannot
find out about a file, it gives the file an even weirder
color.  That might be more useful than the current behavior.
Is this something you could write?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.