Symlinks vs. hardlinks [was: Prevent shutdown with systemctl]

[<tomas@tuxteam.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jan 04, 2016 at 04:43:05PM -0500, Gary Dale wrote:
> On 04/01/16 03:39 PM, tomas@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, 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
> 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.

You can hardlink? I thought the above example shows that I at least can't.
Do try, and come back with results.

Whereas a symlink (which I didn't show above) will be possible without
problems.


> Indeed I can execute systemctl as a normal user by creating a hardlink
> to it.

No. You can execute systemctl as a normal user because it's world-executable,
as Michael showed in this thread. But you won't be able to create a hard
link to it as a normal user. Just try, and you'll see.

>          If that is a problem with symlinks, shouldn't it also be with
> hardlinks?

No, because of above:

  - symlink: permissions of linked-to file apply. Symlink has no "own"
    permissions. When linked-to file is removed, symlink is dangling.

  - hardlink: each has its own metadata (permissions, etc.). All hardlinks
    are equivalent. When last link to a file's data is removed, storage
    is recycled.

They are different concepts, differently implemented. Functionality is
somewhat overlapping, that's why in some situations they can be used
for similar purposes, but for some other things they are radically
different.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlaLeQMACgkQBcgs9XrR2kY/fgCggiJzV2W8uyB0P4XMLQSOPpJ9
CW8AnifbpXbId/+W6L4WM7/6FsoFuMB7
=Vv/R
-----END PGP SIGNATURE-----