-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Jan 04, 2016 at 03:25:02PM -0500, Gary Dale wrote:
On 04/01/16 12:14 PM, tomas@tuxteam.de wrote:
[...]
Dunno about systemctl, but FWIW you can't change the permissions of
a symlink. It's always "all on".
Interesting. Why do they behave that way? Hard links don't (but
replacing the symlink with a hardlink would fail if /bin & /sbin
were on different devices. Also, I gather that systemctl looks at
how it is called to determine the action it needs to take - would
that create a problem if called from a hard link instead of a
symlink?).
Perhaps I was a bit cavalier with my "all on": applications *doing* something
useful with a symlink reference it (except things like "rm", of course).
Thus, the permissions of the referenced-to file apply. Otherwise --
imagine: I do an ln -s /bin/bash $HOME, chmod u+w $HOME/bas
(since I own the link) and now have write access to the system shell?!
Hard links are a completely different kind of animal: they are
alternative directory entries for the same blob of data. Consequently,
there is no "primary" (as there is in symlinks). There are no
dangling hardlinks (unless your file system is corrupted).
As you can well imagine, some restrictions apply in the creation
of hardlinks:
tomas@rasputin:~$ sudo useradd -m test
[sudo] password for tomas:
tomas@rasputin:~$ ls -al /home/test
total 20
drwxr-xr-x 2 test test 4096 Jan 4 21:50 .
drwxr-xr-x 9 root root 4096 Jan 4 21:50 ..
-rw-r--r-- 1 test test 220 Apr 10 2010 .bash_logout
-rw-r--r-- 1 test test 3392 Jul 13 2012 .bashrc
-rw-r--r-- 1 test test 675 Apr 10 2010 .profile
tomas@rasputin:~$ ln /home/test/.profile test-profile
ln: failed to create hard link `test-profile' => `/home/test/.profile': Operation not permitted
Regards
- -- tomás