Hi again, > Am 09.05.2017 um 15:40 schrieb Reuti <[email protected]>: > > 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
