Re: Prevent shutdown with systemctl
On Mon 04 Jan 2016 at 16:43:05 (-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.
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.
Reply to: