Re: Coloring of unreachable symbolic links

[Reuti]

Hi again,

> Am 09.05.2017 um 15:40 schrieb Reuti <address@hidden>:
> 
> 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?

Thinking about this issue and avoiding any ambiguousness: it would even be 
better when this state gets a coloring on its own like (red on gray) for 
"denied symbolic link, while the target exists", being it "de=", "ds=" or "dl". 
Both symbolic links in the example should get this color.

I assume that for now `ls` checks whether the target of a symbolic link can be 
accessed, even without using the symbolic link itself. This would explain, why 
"vvv" is (cyan on white), although it can't be used.

-- Reuti

signature.asc
Description: Message signed with OpenPGP using GPGMail