Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #162587 > unrolled thread

Prevent shutdown with systemctl

Back to article view | Back to linux.debian.user

Contents

  Prevent shutdown with systemctl Floris <jkfloris@dds.nl> - 2016-01-04 17:00 +0100
    Re: Prevent shutdown with systemctl Michael Biebl <biebl@debian.org> - 2016-01-04 18:20 +0100
      Re: Prevent shutdown with systemctl Floris <jkfloris@dds.nl> - 2016-01-04 20:10 +0100
        Re: Prevent shutdown with systemctl Floris <jkfloris@dds.nl> - 2016-01-04 21:00 +0100
          Re: Prevent shutdown with systemctl Michael Biebl <biebl@debian.org> - 2016-01-04 21:20 +0100
        Re: Prevent shutdown with systemctl Brian <ad44@cityscape.co.uk> - 2016-01-04 21:50 +0100
          Re: Prevent shutdown with systemctl Floris <jkfloris@dds.nl> - 2016-01-04 23:50 +0100
            Re: Prevent shutdown with systemctl Michael Biebl <biebl@debian.org> - 2016-01-05 00:50 +0100
              Re: Prevent shutdown with systemctl Brian <ad44@cityscape.co.uk> - 2016-01-05 01:30 +0100
                Re: Prevent shutdown with systemctl Michael Biebl <biebl@debian.org> - 2016-01-05 01:40 +0100
    Re: Prevent shutdown with systemctl Gary Dale <garydale@torfree.net> - 2016-01-04 18:20 +0100
      Re: Prevent shutdown with systemctl <tomas@tuxteam.de> - 2016-01-04 18:50 +0100
        Re: Prevent shutdown with systemctl Stuart Longland <stuartl@longlandclan.id.au> - 2016-01-04 21:20 +0100
          Re: Prevent shutdown with systemctl Gary Dale <garydale@torfree.net> - 2016-01-04 21:40 +0100
            Re: Prevent shutdown with systemctl Stuart Longland <stuartl@longlandclan.id.au> - 2016-01-04 22:10 +0100
              Re: Prevent shutdown with systemctl Gary Dale <garydale@torfree.net> - 2016-01-04 22:50 +0100
                Re: Prevent shutdown with systemctl Michael Biebl <biebl@debian.org> - 2016-01-05 01:20 +0100
                  Re: Prevent shutdown with systemctl Gary Dale <garydale@torfree.net> - 2016-01-05 18:20 +0100
        Re: Prevent shutdown with systemctl Gary Dale <garydale@torfree.net> - 2016-01-04 21:30 +0100
          Re: Prevent shutdown with systemctl Stuart Longland <stuartl@longlandclan.id.au> - 2016-01-04 22:00 +0100
            Re: Prevent shutdown with systemctl David Wright <deblis@lionunicorn.co.uk> - 2016-01-05 05:50 +0100
          Re: Prevent shutdown with systemctl <tomas@tuxteam.de> - 2016-01-04 22:20 +0100
            Re: Prevent shutdown with systemctl Gary Dale <garydale@torfree.net> - 2016-01-04 22:50 +0100
              Re: Prevent shutdown with systemctl David Wright <deblis@lionunicorn.co.uk> - 2016-01-05 06:10 +0100
              Symlinks vs. hardlinks [was: Prevent shutdown with systemctl] <tomas@tuxteam.de> - 2016-01-05 09:40 +0100
                Re: Symlinks vs. hardlinks "Thomas Schmitt" <scdbackup@gmx.net> - 2016-01-05 11:10 +0100
                  Re: Symlinks vs. hardlinks <tomas@tuxteam.de> - 2016-01-05 11:40 +0100
                Re: Symlinks vs. hardlinks [was: Prevent shutdown with systemctl] <tomas@tuxteam.de> - 2016-01-05 16:30 +0100
                Re: Symlinks vs. hardlinks [was: Prevent shutdown with systemctl] David Wright <deblis@lionunicorn.co.uk> - 2016-01-05 16:30 +0100
    Re: Prevent shutdown with systemctl Jude DaShiell <jdashiel@panix.com> - 2016-01-04 19:20 +0100
    Re: Prevent shutdown with systemctl Brian <ad44@cityscape.co.uk> - 2016-01-04 19:30 +0100
      Re: Prevent shutdown with systemctl jdd <jdd@dodin.org> - 2016-01-04 20:10 +0100
        Re: Prevent shutdown with systemctl jdd <jdd@dodin.org> - 2016-01-04 20:30 +0100
        Re: Prevent shutdown with systemctl Chris Bannister <cbannister@slingshot.co.nz> - 2016-01-05 11:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#162630

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.

[toc] | [prev] | [next] | [standalone]

#162612

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

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

[toc] | [prev] | [next] | [standalone]

#162614

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

[toc] | [prev] | [next] | [standalone]

#162631

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#162642 — Re: Symlinks vs. hardlinks

Hi,

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

[toc] | [prev] | [next] | [standalone]

#162644 — Re: Symlinks vs. hardlinks

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

On Tue, Jan 05, 2016 at 11:08:11AM +0100, Thomas Schmitt wrote:
> Hi,
> 
> tomas@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

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

[toc] | [prev] | [next] | [standalone]

#162649 — Re: Symlinks vs. hardlinks [was: Prevent shutdown with systemctl]

-----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), tomas@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.

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

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

[toc] | [prev] | [next] | [standalone]

#162650 — Re: Symlinks vs. hardlinks [was: Prevent shutdown with systemctl]

On Tue 05 Jan 2016 at 09:04:19 (+0100), tomas@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.

[toc] | [prev] | [next] | [standalone]

#162596

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 <jkfloris@dds.nl>
> To: "debian-user@lists.debian.org" <debian-user@lists.debian.org>
> Subject: Prevent shutdown with systemctl
> Resent-Date: Mon,  4 Jan 2016 15:56:13 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
> 
> 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
>

-- 

[toc] | [prev] | [next] | [standalone]

#162597

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?

[toc] | [prev] | [next] | [standalone]

#162599

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

[toc] | [prev] | [next] | [standalone]

#162601

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

[toc] | [prev] | [next] | [standalone]

#162643

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web