[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?
- Coloring of unreachable symbolic links,
Reuti <=