Permissions to logout/reboot (non pi user)

[Peter Ryan]

I've added a new user and added them to the groups "adm sudo audio video". But when I log in as this user (via the Raspbian desktop), I can't log out or reboot.

If I run lxde-pi-shutdown-helper from a terminal, it asks for my password. So presumably, by default, I can't even log out... which is odd!

NOTE: I've added the user to "sudo" rather than going the visudo route... I think it's the "Debian" way these days... but I might be wrong! Anyway, I've been doing that on Debian/Ubuntu for a good few years now and it works fine everywhere else.

[beta-tester]

is the user also listed in the /etc/sudoer file like the user pi?

[Peter Ryan]

is the user also listed in the /etc/sudoer file like the user pi?

No. My user is in the sudo group so shouldn't (IMHO) need it.

If that's the work-around for this bug, then I guess that's what I'll have to do. But I do consider requiring non-passworded sudoer privileges just to log out, a bug!

[ajk]

No. My user is in the sudo group so shouldn't (IMHO) need it.

Your right, it's a bug introduced by the new /usr/bin/lxde-pi-shutdown-helper you get if you have done a apt-get dist-upgrade.

[Peter Ryan]

I've got as far as recompiling lxde-pi-shutdown-helper without "sudo" calls; see lines 31-33 here:
https://github.com/raspberrypi/pishutdo ... shutdown.c

...and that works great! I'll post an issue and possibly a pull request to GitHub, but there's a couple of things I don't know:

1. Whilst I believe removing sudo from the command is correct, perhaps it should check permissions first and perhaps ask for a password or state that the user is not permitted if that was the case, and...

2. I absolutely cannot fathom how permissions are actually set for the following commands:

• halt
  poweroff
  shutdown -h now
  reboot

All of these commands are symlinked to systemctl so file permissions are all the same, and they all work without sudo, except halt which says "requires root". Does systemd have it's own permissions somewhere?

Anyway... that's as far as I've got since I first started moaning about this!

[stderr]

1. Whilst I believe removing sudo from the command is correct, perhaps it should check permissions first and perhaps ask for a password or state that the user is not permitted if that was the case, and...

It should only allow a sudo account to shutdown the system. That is the normal configuration. When I checked using poweroff and shutdown without sudo, which is odd to do since you need sudo to shutdown a Linux system, it asked me which account I wanted to authenticate with. Now the desktops seem to be configured to, at least they can be, to automatically boot without asking for a password at the command line or even into X and if you exit via the X route, not then either. But from the command prompt, shutdown should require sudo and an account that is sudoable.

2. I absolutely cannot fathom how permissions are actually set for the following commands:

• halt
  poweroff
  shutdown -h now
  reboot

All of these commands are symlinked to systemctl so file permissions are all the same, and they all work without sudo,

Then you've changed something. The systemctl command can do various things, some of which require sudo privileges. You'll see that with ifconfig as well, depending on the system. You can view ifconfig settings without sudo, but need sudo to change them. The same sort of situation surely should be the case with systemctl. You can configure an expanded range of things that you want to not require sudo or require sudo on various or all accounts, if for some reason you want that.

[Peter Ryan]

1. Whilst I believe removing sudo from the command is correct, perhaps it should check permissions first and perhaps ask for a password or state that the user is not permitted if that was the case, and...

It should only allow a sudo account to shutdown the system. That is the normal configuration.

Sorry, what I meant was that the lxde-pi-shutdown-helper GUI should probably not be concerning itself with permissions directly; that's for the OS to determine. Instead, I believe it would be better if it tried to logout/reboot/shutdown using the user permissions (which it does it my modified version because I removed "sudo" from it) and ideally handle situations where sudo is required by either telling the user they don't have permissions and/or asking for a password to allow it to elevate permissions using sudo in those situations. I'd write that modification myself if I knew how!

2. I absolutely cannot fathom how permissions are actually set for the following commands:

• halt
  poweroff
  shutdown -h now
  reboot

All of these commands are symlinked to systemctl so file permissions are all the same, and they all work without sudo,

Then you've changed something.

I've not - honest!! I'm using a newly delivered NOOBs preinstalled SD card from a "Raspberry Pi Official Starter Kit" and the few things I've installed and changed should be fairly innocuous.... so from memory, I've created a new user, installed spell-check for Libreoffice, meld, gitg, vim, screen. I have dist-upgraded as well, but I'm wondering from various comments if that's what I should be doing.

I would like to know how permissions to halt/reboot/etc commands are managed though. Then I could compare my current Raspbian image with other images, and perhaps ascertain what has been changed or not.

[HawaiianPi]

Is there a solution to this, because I've run into the same problem?

New user with sudo requiring a password and GUI shutdown is broken.

Same thing happens to user "pi" if you disable the NOPASSWD option in /etc/sudoers (with visudo).
pi ALL=(ALL:ALL) ALL breaks GUI shutdown. Can't even Exit to command line.

Another problem is when I installed Gparted (which requires sudo/root authentication) and then try and launch it from the menu, it asks for the pi user account password, instead of the password of my logged-in account. And yes, I did install it under my account using my password, and the pi account wasn't even logged into the system.

As much as I admire the Raspberry Pi organization, they have really screwed up Debian. In an effort to make it easier for noobs they made it a giant mess for people who want to use it like Linux proper.

So is there a fix for any of this, or is Raspbian just broken for anyone that wants to run it in a secure fashion? (I want it to ask me for my password before doing anything critical, like any normal Linux!)

More info:
My user account was entered in visudo with ALL=(ALL:ALL) ALL and was added to the same groups as the pi user (except for the pi group). System boots to command prompt (no auto-login, no auto-GUI). Latest Raspbian Jessie image, updated.

Thanks.

[MarkHaysHarris777]

... As much as I admire the Raspberry Pi organization, they have really screwed up Debian. In an effort to make it easier for noobs they made it a giant mess for people who want to use it like Linux proper.

So is there a fix for any of this, or is Raspbian just broken for anyone that wants to run it in a secure fashion? (I want it to ask me for my password before doing anything critical, like any normal Linux!)

There is nothing broken. And the situation (which IS mainline gnu+linux at the moment) is not the doings of the RPF--- its the result of using an up-stream distro which has made a major change in its most recent stable edition.

Jessie Raspbian is based on Debian 8 Jessie; jessie is using by default for the first time in debian history -- systemd -- rather than sysvinit.

And, for the record here, systemd is here to stay (no need to re-enter that debate either). There is a reason why halt, reboot, shutdown, and poweroff all symlink to systemctl !

Now then, if you want to fix that, you can ! (its not broken mind you, but you don't have to live with it)

All you need to do is to back-level your system to Wheezy, or, simply revert to sysvinit, rather than continue to use systemd. Frankly, I decided to suckitup and RTFM on systemd|systemctl. Most distros are moving to systemd (certainly debian isn't going back) and Raspbian is using the debian distro recommends, &c.

The more you know about systemd, and the more you use it, the more comfortable you will become with the new mainline way that gnu+linux is working these days.

[HawaiianPi]

There is nothing broken. And the situation (which IS mainline gnu+linux at the moment) is not the doings of the RPF--- its the result of using an up-stream distro which has made a major change in its most recent stable edition.

Jessie Raspbian is based on Debian 8 Jessie; jessie is using by default for the first time in debian history -- systemd -- rather than sysvinit.

And, for the record here, systemd is here to stay (no need to re-enter that debate either). There is a reason why halt, reboot, shutdown, and poweroff all symlink to systemctl !

Now then, if you want to fix that, you can ! (its not broken mind you, but you don't have to live with it)

All you need to do is to back-level your system to Wheezy, or, simply revert to sysvinit, rather than continue to use systemd. Frankly, I decided to suckitup and RTFM on systemd|systemctl. Most distros are moving to systemd (certainly debian isn't going back) and Raspbian is using the debian distro recommends, &c.

The more you know about systemd, and the more you use it, the more comfortable you will become with the new mainline way that gnu+linux is working these days.

I'm sorry, but if there is a menu option for shutdown, and it doesn't work, then something is broken. Logging in as a user with admin rights and no password required is just a bad idea, but that seems to be the "fix" for shutdown (from the GUI menu) at the moment. The other "fix" you mentioned above is not a fix, it's a workaround... for something that's broken.

[MarkHaysHarris777]

I'm sorry, but if there is a menu option for shutdown, and it doesn't work, then something is broken.

... root can shutdown the system, as can the sudoer pi. (nothing is broken there...)

If you add a new user to the system (and that user cannot shutdown the system with the menu option) that is what I would expect! (what is broken)?

I have multiple users on my system... its a multi-user system... why would I allow anyone in my class to shutdown the system because they thought it would be funny, or cute? pi can shutdown the system (that's me) and root can shutdown the system (that's me with sudo) but none of my other users is authorized to shutdown the system...

I am failing to see your point.

[jojopi]

NOTE: I've added the user to "sudo" rather than going the visudo route... I think it's the "Debian" way these days... but I might be wrong!

There appears to be a bug in Raspbian jessie here. All of my Debian systems have a file /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf that says:

Code: Select all

[Configuration]
AdminIdentities=unix-group:sudo

Some of my Raspbian systems are missing this file, so adding a user to the sudo group does not have all of the effects it should. The RPF's raspberrypi-ui-mods adds "AdminIdentities=unix-user:pi", which should never have been necessary because pi is in the sudo group.

The missing file belongs to package policykit-1. The rules makefile in the source package creates it differently between Ubuntu and Debian:

Code: Select all

override_dh_install:
        dh_install
        # on Debian use sudo group; on Ubuntu, also allow the admin group for
        # historical reasons
        if dpkg-vendor --is ubuntu; then \
            /bin/echo -e "[Configuration]\nAdminIdentities=unix-group:sudo;unix-group:admin" > debian/policykit-1/etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf; \
        elif dpkg-vendor --is debian; then \
            /bin/echo -e "[Configuration]\nAdminIdentities=unix-group:sudo" > debian/policykit-1/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf; \
        fi

If /etc/dpkg/origins/default says "Vendor: Raspbian", then neither case matches and the file is not created at all.

I suspect that Debian armhf was still being used as a build platform when the wheezy version of the package was created, while Raspbian was self-hosting by jessie. Also, since is it a configuration file, systems dist-upgraded from wheezy to jessie will have been allowed to keep it.

Does creating the missing file help?

[HawaiianPi]

... root can shutdown the system, as can the sudoer pi. (nothing is broken there...)

No, the user pi can't. Not if you turn off the no password option. With pi set to ALL=(ALL:ALL) ALL in sudoers, it can't shutdown, reboot or even log out of the GUI. It's broken, period.

But thankfully there is someone on the team who has fixed it with a recent update. Thanks to whoever that was!

[Peter Ryan]

All of my Debian systems have a file /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf that says:

Code: Select all

[Configuration]
AdminIdentities=unix-group:sudo

...

Does creating the missing file help?

I created the above file, but sadly, no change!

Just to recap on my observations thus far:

• 1. I've created a user and that user is in the sudo group
  2. That user can reboot from the command line without prefixing the command with sudo
  3. Point 2 - reboot - surprised me! Hence my investigating the command and discovering it symlinked to systemctl.
  4. Given that my user can logout/reboot/shutdown from the command line, it's odd that lxde-pi-shutdown-helper doesn't work... but looking at the source (link to github in previous post) lxde-pi-shutdown-helper uses a system() call and prefixes the logout/reboot/shutdown commands with sudo. So it works with the "pi" user because that user is set NOPASSWD in sudoers, but for users merely in the sudo group, it fails.
  5. In any case, lxde-pi-shutdown-helper doesn't need to prefix commands with sudo because of point 2.
  6. Recompiling lxde-pi-shutdown-helper without "sudo" prefixing it's commands, fixes it!
  7. But I'm still surprised at point 2!! Is systemd using polkit to control access to reboot/shutdown?

I've just submitted a pull request on Github so hopefully that, or a better fix, will be deployed soon.

[HawaiianPi]

...
I've just submitted a pull request on Github so hopefully that, or a better fix, will be deployed soon.

Peter, it appears to already have been fixed. I did an update/upgrade today and it's working for me.

[jojopi]

That user can reboot from the command line without prefixing the command with sudo

It is quite interesting. If you are on console (text or GUI) you can "reboot" without a password. If you are using SSH or VNC you are asked to authenticate via policykit, using either terminal or X11 as appropriate. As you noted originally, "poweroff" works but "halt" does not. Also "shutdown now" is allowed, but not "shutdown +1".

Nevertheless, that all appears to be working the way systemd intends. I agree that lxde-pi-shutdown-helper should not attempt to use sudo.

[Peter Ryan]

Peter, it appears to already have been fixed. I did an update/upgrade today and it's working for me.

It doesn't _seem_ to for me... but if the recent updates fixed the issue jojopi mentioned about missing the file "/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf" then it's possible I've re-broken it myself since updating by manually removing it, which I did because I thought it didn't help, but I _may_ have been mistaken! (see my next post)

[Peter Ryan]

All of my Debian systems have a file /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf that says:

Code: Select all

[Configuration]
AdminIdentities=unix-group:sudo

...
Does creating the missing file help?

I created the above file, but sadly, no change!

Yeah... about that... I might have been mistaken there.

It does seem to work, albeit (this is my defence ) I've had slightly inconsistent results which I suspect may be due to polkit loading it's config files when the lxde session starts and so me creating/deleting config files whilst teh session is running may not work as expected? Or something? Plus the dog ate my homework so it's really not my fault, etc.!

One minor point of possible interest; I've got another Pi running Raspbian-jessie-lite since the start of the year. That machine has no polkit packages installed at all. So what does systemd use for authentication in the absence of that?

[HawaiianPi]

Peter, it appears to already have been fixed. I did an update/upgrade today and it's working for me.

It doesn't _seem_ to for me... but if the recent updates fixed the issue jojopi mentioned about missing the file "/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf" then it's possible I've re-broken it myself since updating by manually removing it, which I did because I thought it didn't help, but I _may_ have been mistaken! (see my next post)

I may have spoken too soon. Exit to command line seems to be working for me, but shutdown and reboot are still freezing the system. Oh well, partially working is better than completely broken, I guess... :p

[spl23]

I've pulled Peter's patch into pishutdown today - for which many thanks - and I have tested the shutdown options under all the circumstances I can think of. You are quite correct that sudo no longer seems to be needed for any of them. (It certainly used to be needed, so something has changed somewhere - presumably this happened in the move to Jessie.)

The new pishutdown will be available with an apt update in the not too distant future.

[ajk]

The new pishutdown will be available with an apt update in the not too distant future.

I believe the current version of pishutdown has re-introduced an old bug.
The line:

Code: Select all

if (!strcmp (data, "exit")) system ("pkill lxsession");

should read

Code: Select all

if (!strcmp (data, "exit")) system ("kill _LXSESSION_PID");

see https://github.com/RPi-Distro/repo/issues/15

[Nickcn]

You can reboot and shutdown the system without sudo for non-Pi user, here is how:

right "Alt"+prtScr/"SysRq" (you may need to push SysRq, then release it), then while still holding "Alt", hit "B", or using left Alt, simply ... "alt"+"sysrq"+"b"

System will reboot, then use shutdown upper right hand corner of screen.


Or just to turn off, do: "alt"+"sysrq"+"o"

Done.

[HawaiianPi]

I've pulled Peter's patch into pishutdown today - for which many thanks - and I have tested the shutdown options under all the circumstances I can think of. You are quite correct that sudo no longer seems to be needed for any of them. (It certainly used to be needed, so something has changed somewhere - presumably this happened in the move to Jessie.)

The new pishutdown will be available with an apt update in the not too distant future.

Good to hear, because after doing a sudo apt-get update && sudo apt-get dist-upgrade it's very broken again. But the problems seem to be more than just pishutdown, because almost everything in the menu that requires admin rights fails to ask for a password and just locks the system up if you don't have the NOPASSWD option set in visudo.

I really don't want to run with NOPASSWD, but the Raspbian GUI/desktop seems to be very broken without it.

I have my users set as ALL=(ALL:ALL) ALL with visudo, and my users are in the "sudo" group.

When I use the menu to launch something like the new SD Card Copier, it just locks-up the system instead of asking for a password, because it seems to assume the NOPASSWD option will be set. I have been fixing these things as I find them by adding gksu /usr/bin/ before the application name, which forces Raspbian to ask for a password, but this shouldn't be necessary.

The Raspberry Pi is supposed to be a teaching tool, so shouldn't we be teaching people to use Linux properly? I mean, if you are going to allow people to login to the system with admin rights and NOPASSWD, you might as well just give root a password and login as root (the "pi" user is just as bad).

You can reboot and shutdown the system without sudo for non-Pi user, here is how:

right "Alt"+prtScr/"SysRq" (you may need to push SysRq, then release it), then while still holding "Alt", hit "B", or using left Alt, simply ... "alt"+"sysrq"+"b"

System will reboot, then use shutdown upper right hand corner of screen.


Or just to turn off, do: "alt"+"sysrq"+"o"

Done.

The correct way to do that is alt+sysreq R E I S U B (hold alt+sysreq then press each of the r e i s u b keys in sequence with a few seconds delay between each). What you are proposing forces a reboot or shutdown without cleanly exiting the filesystem. Might as well just pull the power plug. An easy mnemonic to use to remember that is, Reboot Even If System Utterly Broken (substitute "o" for "b" to power off).

Aloha, Tim

[jojopi]

But the problems seem to be more than just pishutdown, because almost everything in the menu that requires admin rights fails to ask for a password and just locks the system up if you don't have the NOPASSWD option set in visudo.

In the case of piclone, it is just bad. See "strings /usr/bin/piclone |grep sudo" and then you might want to purge it.

Otherwise the correct solution would be to launch the whole application using gksudo or gksu or pkexec, which know how to prompt for authentication using X11, and remove all references to sudo from within. (Replacing the internal sudos with gksudo will not really work, because that would be making assumptions about the sudo timeout configuration. Anyway, programs should never use sudo internally unless they are authenticating as their own user, not impersonating the user who ran them.)

For the gparted-pkexec problem in your previous thread, I think that the missing 51-debian-sudo.conf I mentioned above may be the reason it works for pi but not for all sudo members. That is a Raspbian bug, rather than just something odd in the Foundation's images.

Do you have other examples of stuff in the menus that does not prompt for the right authentication?

The Raspberry Pi is supposed to be a teaching tool, so shouldn't we be teaching people to use Linux properly? I mean, if you are going to allow people to login to the system with admin rights and NOPASSWD, you might as well just give root a password and login as root (the "pi" user is just as bad).

You certainly should be allowed the sudo configuration you want, but I do not follow the rest of your logic here.

Logging in as root means that all processes run as root, all discretionary access controls are ignored, and some applications may not even work correctly. That is not using Linux properly. Logging in as a regular user but having sudo with NOPASSWD means that permissions are honoured normally, but you can override them for any specific commands.

If you are already logged in, you probably know your own password, so asking for it again is really just an inconvenience. If you leave your terminal unattended, or run scripts from untrustworthy sources, having sudo configured to require a password is not going to protect you. Your account it compromised and it is trivial for the attacker to sniff your password, or simply run their own commands, the next time you legitimately try to sudo or su.

[HawaiianPi]

In the case of piclone, it is just bad. See "strings /usr/bin/piclone |grep sudo" and then you might want to purge it.

Not on my Pi right now, but I'll take a look at that later. Thanks.

Otherwise the correct solution would be to launch the whole application using gksudo or gksu or pkexec, which know how to prompt for authentication using X11, and remove all references to sudo from within. (Replacing the internal sudos with gksudo will not really work, because that would be making assumptions about the sudo timeout configuration. Anyway, programs should never use sudo internally unless they are authenticating as their own user, not impersonating the user who ran them.)

Yea, my "fix" so far has been to add gksu to the GUI menu application calls.

For the gparted-pkexec problem in your previous thread, I think that the missing 51-debian-sudo.conf I mentioned above may be the reason it works for pi but not for all sudo members. That is a Raspbian bug, rather than just something odd in the Foundation's images.

That worked until I did a dist-upgrade earlier today, then that broke again (even with the missing file added). Got that working again by adding the gksu call to the menu (again).

Do you have other examples of stuff in the menus that does not prompt for the right authentication?

Don't recall what else at the moment.

You certainly should be allowed the sudo configuration you want, but I do not follow the rest of your logic here.

Logging in as root means that all processes run as root, all discretionary access controls are ignored, and some applications may not even work correctly. That is not using Linux properly.

That's the point I was trying to make, but I'll admit it wasn't a perfect analogy.

If you are already logged in, you probably know your own password, so asking for it again is really just an inconvenience. If you leave your terminal unattended, or run scripts from untrustworthy sources, having sudo configured to require a password is not going to protect you. Your account it compromised and it is trivial for the attacker to sniff your password, or simply run their own commands, the next time you legitimately try to sudo or su.

Except the malicious script or application would not be able to run without you knowing it (you would have to enter your password at least once), which it can the way it is now, so we can agree to disagree on that one. I still think it's a security risk and a poor way to use Linux.

Thanks, Tim