Prevent shutdown with systemctl

[Floris]

Dear list,

Often there are multiple users working on my multiseat [1] system, some of
them are kids and they are not paying attention if someone else is logged
in. They can shutdown the computer even if someone else is logged in and
have an active session.

Is it possible that only root can shutdown/ reboot the computer if
multiple users are logged in and when there is only one user that user is
able to shutdown the computer?

Thanks,

Floris

[1] https://en.wikipedia.org/wiki/Multiseat_configuration

[Gary Dale]

/sbin/reboot is a link that allows anyone to execute it. It points to
/bin/systemctl that also allows anyone to execute it. The first part of
your problem can be solved simply with fixing the permissions for
reboot, shutdown & poweroff.

The second part would be to track the users on the system (users | wc)
and change the permissions as it changes between 1 and more than 1.

This is a bit of a brute force technique but it should work.

[Michael Biebl]

Am 04.01.2016 um 16:55 schrieb Floris:
> Dear list,
>
> Often there are multiple users working on my multiseat [1] system, some
> of them are kids and they are not paying attention if someone else is
> logged in. They can shutdown the computer even if someone else is logged
> in and have an active session.

What command exactly do they use?

> Is it possible that only root can shutdown/ reboot the computer if
> multiple users are logged in and when there is only one user that user
> is able to shutdown the computer?

That works here with the default configuration:

$ systemctl poweroff
User root is logged in on /dev/tty1.
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl poweroff -i'.


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[to...@tuxteam.de]

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

On Mon, Jan 04, 2016 at 12:16:03PM -0500, Gary Dale wrote:
> On 04/01/16 10:55 AM, Floris wrote:
> >Dear list,
> >
> >Often there are multiple users working on my multiseat [1] system,
> >some of them are kids and they are not paying attention if someone
> >else is logged in. They can shutdown the computer even if someone
> >else is logged in and have an active session.
> >
> >Is it possible that only root can shutdown/ reboot the computer if
> >multiple users are logged in and when there is only one user that
> >user is able to shutdown the computer?
> >
> >Thanks,
> >
> >Floris
> >
> >[1] https://en.wikipedia.org/wiki/Multiseat_configuration
> >
> /sbin/reboot is a link that allows anyone to execute it. It points
> to /bin/systemctl that also allows anyone to execute it. The first
> part of your problem can be solved simply with fixing the
> permissions for reboot, shutdown & poweroff.

Dunno about systemctl, but FWIW you can't change the permissions of
a symlink. It's always "all on".

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

iEYEARECAAYFAlaKqF0ACgkQBcgs9XrR2kadZACfRLyCoHjH+KQ6bwKMrpKiBiS8
i6oAniURn3PkdfoMZTVBkDpsdjEmqo+g
=P6i8
-----END PGP SIGNATURE-----

[Jude DaShiell]

Put each subaccount one per line into /etc/shutdown.deny then reboot.

On Mon, 4 Jan 2016, Floris wrote:

> Date: Mon, 4 Jan 2016 10:55:56
> From: Floris <jkfl...@dds.nl>
> To: "debia...@lists.debian.org" <debia...@lists.debian.org>
> Subject: Prevent shutdown with systemctl
> Resent-Date: Mon, 4 Jan 2016 15:56:13 +0000 (UTC)
> Resent-From: debia...@lists.debian.org

--

[Brian]

On Mon 04 Jan 2016 at 16:55:56 +0100, Floris wrote:

> Often there are multiple users working on my multiseat [1] system, some of
> them are kids and they are not paying attention if someone else is logged
> in. They can shutdown the computer even if someone else is logged in and
> have an active session.
>
> Is it possible that only root can shutdown/ reboot the computer if multiple
> users are logged in and when there is only one user that user is able to
> shutdown the computer?

A hint, please, Which DE are you using?

[jdd]

>> Is it possible that only root can shutdown/ reboot the computer if multiple
>> users are logged in and when there is only one user that user is able to
>> shutdown the computer?

time ago, the question was asked at each install. There is certainly an
option "who can shut down the computer", but do not forget to hide
switches...

here:

https://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html

see

4.8 Restricting system reboots through the console

mostly:

If you want to restrict this, you must check the /etc/inittab so that
the line that includes ctrlaltdel calls shutdown with the -a switch.

(but not only, see shutdown man page)

jdd

[Floris]

Op Mon, 04 Jan 2016 18:16:39 +0100 schreef Michael Biebl
<bi...@debian.org>:

> Am 04.01.2016 um 16:55 schrieb Floris:
>> Dear list,
>>
>> Often there are multiple users working on my multiseat [1] system, some
>> of them are kids and they are not paying attention if someone else is
>> logged in. They can shutdown the computer even if someone else is logged
>> in and have an active session.
>
> What command exactly do they use?
>

the power off button in gnome3.18

There is a warning that an other user is logged in, but all users are
able to shutdown/ reboot.

[jdd]

Le 04/01/2016 20:03, jdd a écrit :

> (but not only, see shutdown man page)

in kde control center, under login, there is a tab for shutdown

jdd

[Floris]

Op Mon, 04 Jan 2016 20:03:33 +0100 schreef Floris <jkfl...@dds.nl>:

In a terminal I get the expected behavior:
floris@Jessica:~$ systemctl poweroff
Operation inhibited by "julian" (PID 1246 "gnome-session-b", user julian),
reason is "user session inhibited".
User julian is logged in on /dev/tty2.

[Michael Biebl]

Hi Floris,

Am 04.01.2016 um 20:53 schrieb Floris:
> Op Mon, 04 Jan 2016 20:03:33 +0100 schreef Floris <jkfl...@dds.nl>:
>
>> Op Mon, 04 Jan 2016 18:16:39 +0100 schreef Michael Biebl
>> <bi...@debian.org>:
>>
>>> Am 04.01.2016 um 16:55 schrieb Floris:
>>>> Dear list,
>>>>
>>>> Often there are multiple users working on my multiseat [1] system, some
>>>> of them are kids and they are not paying attention if someone else is
>>>> logged in. They can shutdown the computer even if someone else is
>>>> logged
>>>> in and have an active session.
>>>
>>> What command exactly do they use?
>>>
>>
>> the power off button in gnome3.18
>>
>> There is a warning that an other user is logged in, but all users are
>> able to shutdown/ reboot.

This action is configurable.

See /usr/share/polkit-1/actions/org.freedesktop.login1.policy

Active users can override the warning for the
org.freedesktop.login1.power-off-multiple-sessions
action.

You can lock that down via a policykit rule though.

Can you tell me which policykit-1 version you are using?
--

[Stuart Longland]

On 05/01/16 03:14, to...@tuxteam.de wrote:
> On Mon, Jan 04, 2016 at 12:16:03PM -0500, Gary Dale wrote:
>> On 04/01/16 10:55 AM, Floris wrote:
>>> Dear list,
>>>
>>> Often there are multiple users working on my multiseat [1] system,
>>> some of them are kids and they are not paying attention if someone
>>> else is logged in. They can shutdown the computer even if someone
>>> else is logged in and have an active session.
>>>
>>> Is it possible that only root can shutdown/ reboot the computer if
>>> multiple users are logged in and when there is only one user that
>>> user is able to shutdown the computer?
>>>
>>> Thanks,
>>>
>>> Floris
>>>
>>> [1] https://en.wikipedia.org/wiki/Multiseat_configuration
>>>
>> /sbin/reboot is a link that allows anyone to execute it. It points
>> to /bin/systemctl that also allows anyone to execute it. The first
>> part of your problem can be solved simply with fixing the
>> permissions for reboot, shutdown & poweroff.
>
> Dunno about systemctl, but FWIW you can't change the permissions of
> a symlink. It's always "all on".

Changing the permissions of the "linked-to" file would be sufficient then.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[Gary Dale]

On 04/01/16 12:14 PM, to...@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Jan 04, 2016 at 12:16:03PM -0500, Gary Dale wrote:
>> On 04/01/16 10:55 AM, Floris wrote:
>>> Dear list,
>>>
>>> Often there are multiple users working on my multiseat [1] system,
>>> some of them are kids and they are not paying attention if someone
>>> else is logged in. They can shutdown the computer even if someone
>>> else is logged in and have an active session.
>>>
>>> Is it possible that only root can shutdown/ reboot the computer if
>>> multiple users are logged in and when there is only one user that
>>> user is able to shutdown the computer?
>>>
>>> Thanks,
>>>
>>> Floris
>>>
>>> [1] https://en.wikipedia.org/wiki/Multiseat_configuration
>>>
>> /sbin/reboot is a link that allows anyone to execute it. It points
>> to /bin/systemctl that also allows anyone to execute it. The first
>> part of your problem can be solved simply with fixing the
>> permissions for reboot, shutdown & poweroff.
> 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?).

[Gary Dale]

Possibly but I note that systemctl is owned by root:root so that typical
users can't execute it anyway. They get execute rights from the links.
Systemctl seems to figure out what to do based on the link that calls it
and the current system policy.

Replacing the symlinks with hardlinks might work providing that /bin and
/sbin are on the same devices, which they usually are.

[Brian]

On Mon 04 Jan 2016 at 20:03:33 +0100, Floris wrote:

> Op Mon, 04 Jan 2016 18:16:39 +0100 schreef Michael Biebl <bi...@debian.org>:
>
> >Am 04.01.2016 um 16:55 schrieb Floris:
> >>Dear list,
> >>
> >>Often there are multiple users working on my multiseat [1] system, some
> >>of them are kids and they are not paying attention if someone else is
> >>logged in. They can shutdown the computer even if someone else is logged
> >>in and have an active session.
> >
> >What command exactly do they use?
>
> the power off button in gnome3.18
>
> There is a warning that an other user is logged in, but all users are
> able to shutdown/ reboot.

Devise a file to put in /etc/polkit-1/localauthority/50-local.d after
you have read pklocalauthority(8). Works for me.

[Stuart Longland]

On 05/01/16 06:25, Gary Dale wrote:
> 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?).

Well, /bin and /sbin can't be on different devices because the first
thing the kernel executes (unless told to do so otherwise) is
/sbin/init, and if /bin/mount were on a different device, it would not
be accessible.

Classic chicken-egg problem.

These days, even /usr on a different partition is considered a no no, at
least in the Church of udev.

http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

As for symlink behaviour, directory entities all occupy inodes, and a
symbolic link is a special type of directory entity whose content points
to another by name.

A hard link is basically a directory entry that, rather than having its
own inode, it shares the same inode as some other directory entity.
It's the directory entity that has the metadata such as file name,
permissions and ownership.

[Stuart Longland]

On 05/01/16 06:30, Gary Dale wrote:
> Possibly but I note that systemctl is owned by root:root so that typical
> users can't execute it anyway. They get execute rights from the links.

Errm, no they wouldn't. Not if they were symlinks. Hardlinks, maybe.

> Systemctl seems to figure out what to do based on the link that calls it
> and the current system policy.

It probably detects this from argv[0], which by convention is always the
name of the file executed. Since that file is the symbolic link, the
name of that symbolic link is what's passed as the first argument in argv.

Permissions, as it's usually the equivalent of a `stat` rather than a
`lstat` system call, will come from the actual binary, which is
world-executable. The only thing that stops a user from actually
shutting the machine down is the fact that sysctl does all sorts of
voodoo to figure out who you are first before giving the nod to init.

[to...@tuxteam.de]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlaK2GoACgkQBcgs9XrR2kZg+QCfQoqu5lph/Nh7ZyDOFv0jwG7y
aDkAn29+qk8cLS3je2DKwMUk3lvt2o3F
=8Nmr
-----END PGP SIGNATURE-----

[Gary Dale]

On 04/01/16 04:05 PM, Stuart Longland wrote:
> On 05/01/16 06:30, Gary Dale wrote:
>> Possibly but I note that systemctl is owned by root:root so that typical
>> users can't execute it anyway. They get execute rights from the links.
> Errm, no they wouldn't. Not if they were symlinks. Hardlinks, maybe.
>
>> Systemctl seems to figure out what to do based on the link that calls it
>> and the current system policy.
> It probably detects this from argv[0], which by convention is always the
> name of the file executed. Since that file is the symbolic link, the
> name of that symbolic link is what's passed as the first argument in argv.
>
> Permissions, as it's usually the equivalent of a `stat` rather than a
> `lstat` system call, will come from the actual binary, which is
> world-executable. The only thing that stops a user from actually
> shutting the machine down is the fact that sysctl does all sorts of
> voodoo to figure out who you are first before giving the nod to init.

The link is to /bin/systemctl which is NOT world executable and is owned
by root:root. Therefore it should not be executable by anyone other than
root. Neither apparently is the symlink, so your are right on that
point. The original poster asked about using systemctl so I assumed he
was actually using it directly

Figuring my way through this, it must be that the various DMs that
provide the shutdown buttons work some magic to allow normal users to
shutdown computers. This of course means that any approach using
permissions on the actual program or links cannot work.

[Gary Dale]

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. Indeed I can execute
systemctl as a normal user by creating a hardlink to it. If that is a
problem with symlinks, shouldn't it also be with hardlinks?

[Floris]

Op Mon, 04 Jan 2016 21:43:10 +0100 schreef Brian <ad...@cityscape.co.uk>:

Thanks Michael and Brain for giving the right clues.

I made the file
/etc/polkit-1/localauthority/50-local.d/10-disable-reboot.pkla

with

[Disable poweroff and reboot]
Identity=unix-user:julian;unix-user:eugenie
Action=org.freedesktop.login1.power-off-multiple-sessions;org.freedesktop.login1.reboot-multiple-sessions
ResultActive=auth_admin_keep

Two questions
- there is also a /etc/polkit-1/rules.d directory. When and how do you use
that directory?
- How can I point to all users by 'Identity='?

to Michael

> Can you tell me which policykit-1 version you are using?

policykit-1:amd64/testing 0.105-14
policykit-1-gnome:amd64/testing 0.105-2

Maybe there is a reason. Why is the default rule:

<action id="org.freedesktop.login1.power-off-multiple-sessions">
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>
<allow_active>yes</allow_active>
</defaults>

instead of
...
<allow_active>auth_admin_keep</allow_active>
...

Thanks for the information

Floris

[Michael Biebl]

This directory is for policykit-1 from experimental.
Not sure why you have that directory.
Maybe you installed policykit-1 from experimental some time ago and
downgraded again (which won't remove the conffiles).

> - How can I point to all users by 'Identity='?

Identity=unix-user:* should work

> to Michael
>> Can you tell me which policykit-1 version you are using?
> policykit-1:amd64/testing 0.105-14
> policykit-1-gnome:amd64/testing 0.105-2
>
> Maybe there is a reason. Why is the default rule:
>
> <action id="org.freedesktop.login1.power-off-multiple-sessions">
> <allow_any>auth_admin_keep</allow_any>
> <allow_inactive>auth_admin_keep</allow_inactive>
> <allow_active>yes</allow_active>
> </defaults>
>
> instead of
> ...
> <allow_active>auth_admin_keep</allow_active>
> ...

The reasoning here is, that someone who is active and local has physical
access, so could shutdown the system via other means anyway (pull the plug).

Michael

[Michael Biebl]

Am 04.01.2016 um 22:43 schrieb Gary Dale:

> The link is to /bin/systemctl which is NOT world executable and is owned
> by root:root. Therefore it should not be executable by anyone other than
> root.

$ ls -al /bin/systemctl
-rwxr-xr-x 1 root root 651512 Jan 2 20:17 /bin/systemctl

systemctl is executable by everyone, not just root.
So your information is incorrect.

[Brian]

I see the argument, it is explained more fully at

https://lists.debian.org/debian-devel/2015/08/msg00354.html ,

but am not completely persuaded by the "annoyance" factor. In the early
days of systemd the default was indeed auth_admin_keep for active users.

I have not tried policykit from experimental but believe the format of a
localauthority file has changed to use JavaScript. Will present .pkla
files continue to work with this version of policykit?

[Michael Biebl]

Am 05.01.2016 um 01:24 schrieb Brian:

> I have not tried policykit from experimental but believe the format of a
> localauthority file has changed to use JavaScript.

Correct.

Will present .pkla
> files continue to work with this version of policykit?

Not out of the box. There is an addon [1], which also reads the old pkla
files under the new policykit. But I'm not convinced this is actually a
good idea. Having the old and new rules side by side makes it really
hard to determine which one actually takes effect.

I'm not a huge fan of the new, JS-based format, fwiw. Which is the main
reason policykit-1 (>= 0.106) is not in Debian unstable.

Michael

[1] https://fedorahosted.org/polkit-pkla-compat/

[David Wright]

On Tue 05 Jan 2016 at 06:57:28 (+1000), Stuart Longland wrote:
>
> As for symlink behaviour, directory entities all occupy inodes, and a
> symbolic link is a special type of directory entity whose content points
> to another by name.
>
> A hard link is basically a directory entry that, rather than having its
> own inode, it shares the same inode as some other directory entity.
> It's the directory entity that has the metadata such as file name,

Yes, the directory entry has the filename and inode number...

> permissions and ownership.

... but these are in the inode, along with size and location.

Cheers,
David.

[David Wright]

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.

[to...@tuxteam.de]

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

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-----

[Thomas Schmitt]

Hi,

to...@tuxteam.de wrote:
> > > tomas@rasputin:~$ ln /home/test/.profile test-profile
> > > ln: failed to create hard link `test-profile' =>
> > > `/home/test/.profile': Operation not permitted

Seems to be a new security feature.

In "man 5 proc" i read
"/proc/sys/fs/protected_hardlinks (since Linux 3.6)
...
When the value in this file is 1, a hard
link can be created to a target file only if one of the follow‐
ing conditions is true:
...
* The caller has the CAP_FOWNER capability.
* The filesystem UID of the process creating the link matches
the owner (UID) of the target file [...]
* All of the following conditions are true:
...
· the caller has permission to read and write the target
file
"

So it is not enough to have w-permission of the directory where
the new link shall emerge. Ownership or rw-permission of the target
file is needed, too.

The described behavior is in effect here:

$ cat /proc/sys/fs/protected_hardlinks
1


Have a nice day :)

Thomas

[Chris Bannister]

On Mon, Jan 04, 2016 at 08:03:48PM +0100, jdd wrote:
> https://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html
>
> see
>
> 4.8 Restricting system reboots through the console
>
> mostly:
>
> If you want to restrict this, you must check the /etc/inittab so that the
> line that includes ctrlaltdel calls shutdown with the -a switch.

I was under the impression that /etc/inittab has no influence on
anything if using systemd, which is the default.

Is that advice in that manual? Does it hint at anything related to
systemd?

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[to...@tuxteam.de]

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

Thank you for showing this old dog a new trick :-)

> Have a nice day :)

and a happy new year

regards

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

iEYEARECAAYFAlaLk1EACgkQBcgs9XrR2kYpcgCfbnpk3pmfNLNnkmnXVCKScGyH
xIMAmwY99dP6m8vN6h7NJl6ikF+ry4Zu
=FQA0
-----END PGP SIGNATURE-----

[David Wright]

On Tue 05 Jan 2016 at 09:04:19 (+0100), to...@tuxteam.de wrote:
> On Mon, Jan 04, 2016 at 04:43:05PM -0500, Gary Dale wrote:
> > 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.

That could be interpreted ambiguously. To clarify, the metadata is
stored in the inode, so all the hard links to a particular file/inode
share the same information, thus:

07:45 $ touch foo
07:45 $ ls -li [fb]*
488715 -rw-r----- 1 david david 0 Jan 5 07:45 foo
07:45 $ ln foo bar
07:55 $ ls -li [fb]*
488715 -rw-r----- 2 david david 0 Jan 5 07:45 bar
488715 -rw-r----- 2 david david 0 Jan 5 07:45 foo
07:55 $ chmod a+r bar
07:57 $ ls -li [fb]*
488715 -rw-r--r-- 2 david david 0 Jan 5 07:45 bar
488715 -rw-r--r-- 2 david david 0 Jan 5 07:45 foo
07:57 $ touch bar
07:57 $ ls -li [fb]*
488715 -rw-r--r-- 2 david david 0 Jan 5 07:57 bar
488715 -rw-r--r-- 2 david david 0 Jan 5 07:57 foo
07:57 $ ls -li [fb]*
488715 -rw-r--r-- 2 david david 0 Jan 5 07:57 bar
488715 -rw-r--r-- 2 david david 0 Jan 5 07:57 foo
07:58 $

# chown nobody /tmp/bar

07:58 $ ls -li [fb]*
488715 -rw-r--r-- 2 nobody david 0 Jan 5 07:57 bar
488715 -rw-r--r-- 2 nobody david 0 Jan 5 07:57 foo
07:59 $

Each symlink has its own metadata in its inode, but most of it
is ignored most of the time (eg ownership), or can't be changed
(eg permissions).

> 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.

Cheers,
David.

[to...@tuxteam.de]

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

On Tue, Jan 05, 2016 at 09:19:57AM -0600, David Wright wrote:
> On Tue 05 Jan 2016 at 09:04:19 (+0100), to...@tuxteam.de wrote:
> > On Mon, Jan 04, 2016 at 04:43:05PM -0500, Gary Dale wrote:
> > > 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.
>
> That could be interpreted ambiguously. To clarify, the metadata is
> stored in the inode, so all the hard links to a particular file/inode
> share the same information, thus:

You are too polite. What I wrote is plainly wrong on a second look.
Sorry. Yes, the metadata is in the inode and not in the directory
entry.

Spot on. Thanks for the correction (and for your politeness :)

regards

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

iEYEARECAAYFAlaL2TEACgkQBcgs9XrR2kY9KQCffkTMtTA1gt0qLt94NUM9subh
VBoAn195zfUGSv9DVwjFmZCstTQTKSRZ
=mjYZ
-----END PGP SIGNATURE-----

[Gary Dale]

On 04/01/16 07:16 PM, Michael Biebl wrote:
> Am 04.01.2016 um 22:43 schrieb Gary Dale:
>
>> The link is to /bin/systemctl which is NOT world executable and is owned
>> by root:root. Therefore it should not be executable by anyone other than
>> root.
> $ ls -al /bin/systemctl
> -rwxr-xr-x 1 root root 651512 Jan 2 20:17 /bin/systemctl
>
> systemctl is executable by everyone, not just root.
> So your information is incorrect.
>
>

You are correct. The system I checked it on appears to be an anomaly.