coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Coloring of unreachable symbolic links


From: Reuti
Subject: Coloring of unreachable symbolic links
Date: Tue, 9 May 2017 15:40:43 +0200

Hi,

I was confused by the output of `ls` (coreutils 8.27) and the non corresponding 
behavior when trying to access some files. Essentially it was a set 
fs.protected_symlinks=1 which was the reason, but the coloring in `ls` did not 
reflect it.

Looking into this, I found that `ls` on it's own uses cyan on white for 
symlinks, whether they are valid and sensible or not. Using `dircolors` 
beforehand to set LS_COLORS shows orphaned symbolic links with red on black by 
setting a value for "or=40;31;01".

In a directory with the "sticky bit set" and enabled "fs.protected_symlinks=1", 
I got this as user "foo":

-rw-r--r--  1 soft     users       0 May  9 14:17 uuu
lrwxrwxrwx  1 soft     users       3 May  9 14:18 vvv -> uuu
lrwxrwxrwx  1 soft     users       3 May  9 14:39 www -> vvv

Any user "foo" belonging to group "users" can access the file "uuu" to list it 
(black on white is ok). But he can't use the symbolic link "vvv", nevertheless 
it is listed as (cyan on white). On the other hand, the symbolic link "www" is 
shown as (red on black) as the target "vvv" can't be reached.

I can use -L and both symbolic links appear in (red on black).

Question: why is "vvv" still printed in (cyan on white) by default, although it 
can't be reached?

-- Reuti

PS: I can use 'dircolors --print-database' to show all settings, but where are 
the codes for setting "or=..." and alike are documented?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]