On Mon 04 Jan 2016 at 16:43:05 (-0500), Gary Dale wrote: > On 04/01/16 03:39 PM, to...@tuxteam.de wrote: > >-----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, to...@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 > Actually I don't see it that way at all. The symlink example is no > different from the hardlink case in that I can create a hardlink > that has different permissions than the original file.
It would be interesting to see some support of this view, like the output of ls -li showing the same inode numbers and the different permissions. BTW the concept of "original file" is rendered meaningless with hard links; all the links have the same status. > Indeed I can > execute systemctl as a normal user by creating a hardlink to it. As pointed out already, anyone can execute systemctl if you haven't mangled its proper permissions. Again, could you please show us the hard links and their locations. > If > that is a problem with symlinks, shouldn't it also be with > hardlinks? It might be worthwhile taking a look at man 2 link, man 2 symlink and man 7 symlink. Cheers, David.
