Bug 804088

(In reply to comment #0)
> Systemd implements: full-featured, multi-seat-aware, polkit-managed reboot
> and poweroff control for normal users. The policy is centrally managed like
> all other modern privileged-system-process user management.
"Centrally managed" by what?  IPA?  AFAICT that doesn't exist, support in sssd has been "deferred".


> With Fedora 17, all system reboot, poweroff policy is full provided and
> enforced by systemd and no other legacy policy mechanism should interfere
> or be able to intercept this. Escalating security by intercepting systemd
> tools with consolehelper and granting root privileges that way should no
> longer be accepted nor is it the desired behaviour.
> 
> Please remove:
>   /etc/security/console.apps/halt
>   /etc/security/console.apps/poweroff
>   /etc/security/console.apps/reboot
>   /usr/bin/halt
>   /usr/bin/poweroff
>   /usr/bin/reboot
> 
> entirely from the usermode package.

Does the polkit support in /bin/systemctl actually provide equivalent functionality?

Right now I can edit /etc/pam.d/reboot to e.g. allow a specified user to shutdown/reboot the system from a ssh session.

The default polkit policy for org.freedesktop.login1.* is supposedly configurable in the same way - and the default for an user that is not at the console is auth_admin_keep, so presumably it should prompt me for a root password (and this does work when logged in X).

But, when I ssh in:
> [mitr@f17 ~]$ /sbin/reboot 
> Must be root.
just like that, with no prompt.  What am I doing wrong?

(In reply to comment #1)
> But, when I ssh in:
> > [mitr@f17 ~]$ /sbin/reboot 
> > Must be root.
> just like that, with no prompt.  What am I doing wrong?

To make this work, /bin/systemctl needs to register as an authentication agent ... if it deems that no agent is currently available, e.g. if polkit returns an AuthorizationResult, see

 http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-struct-AuthorizationResult

where is_authorized is FALSE and is_challenge is TRUE.

The end of this commit

 http://cgit.freedesktop.org/PolicyKit/commit/?id=42177383585e1e01cd6150f891176afcd4538a82

shows how this can be done.

If you are allergic to libpolkit-agent.so and its dependencies (you really shouldn't be), you can always dlopen() that shared object... all you need is to call polkit_agent_text_listener_new(), polkit_agent_listener_register() ... then ask polkit again... and then call polkit_agent_listener_unregister(). Oh, and you also need to call g_type_init() before doing anything else, of course.

(In reply to comment #1)
> "Centrally managed" by what?

Centrally managed in the sense of uniform across all actively maintained
projects which grant privileges to ordinary users.

Fedora uses the localauthority by default, which is 'local' like PAM, but
a lot more fine-grained:
  http://hal.freedesktop.org/docs/polkit/pklocalauthority.8.html

Google e.g. recently added upstream their network-based backend, to supply
policy to clients:
  http://cgit.freedesktop.org/PolicyKit/commit/?id=674357c20c1b6cb421fea6eb6924b274ec477c0e

> Does the polkit support in /bin/systemctl actually provide equivalent
> functionality?

It does. And a lot more.
 
> Right now I can edit /etc/pam.d/reboot to e.g. allow a specified user to
> shutdown/reboot the system from a ssh session.

It all works in Fedora 17, besides the password query on seat-less (ssh)
sessions.

> The default polkit policy for org.freedesktop.login1.* is supposedly
> configurable in the same way - and the default for an user that is not at the
> console is auth_admin_keep, so presumably it should prompt me for a root
> password (and this does work when logged in X).

Yeah, X has an polkit agent registered that makes it work. We just added
the that part to systemctl, which took its time, because it needs to be fully
decoupled and async, and there must never be code in the UI, especially
not in X, be executed as uid==0 before the actual privilege is granted.

> But, when I ssh in:
> > [mitr@f17 ~]$ /sbin/reboot 
> > Must be root.
> just like that, with no prompt.  What am I doing wrong?

Nothing wrong, you are just too fast. :)
It's all in F17, besides the seat-less stuff.

It's all on the way now:
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=6bb92a169e8a65e7def5545798001e0dbecc7d4f

Looks like this:

$ ==== AUTHENTICATING FOR org.freedesktop.login1.reboot ===
Authentication is required to allow rebooting the system
Authenticating as: Kay Sievers (kay)
Password: 
==== AUTHENTICATION COMPLETE ===
Stopping Serial Getty on ttyS0... 
...

(In reply to comment #3)
> > Right now I can edit /etc/pam.d/reboot to e.g. allow a specified user to
> > shutdown/reboot the system from a ssh session.
> 
> It all works in Fedora 17, besides the password query on seat-less (ssh)
> sessions.
<snip>
> It's all on the way now:
>  
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=6bb92a169e8a65e7def5545798001e0dbecc7d4f

Thanks.

Considering that
* I'd really prefer to avoid this regression,
* F17 beta has already been declared gold, and
* F17 release notes have been frozen (for translation) at least since Apr 6,
this is a F18 material.

Can you ping me when the systemd release with this commit lands in rawhide, please?  (If not, I'll get back to this during my regular bug review, but that may again happen sometime around Alpha.)

Please entirely drop the consolehelper interception for the reboot commands,
it does the wrong things and needs to stay out of the way. Thanks!

(In reply to comment #5)
> Please entirely drop the consolehelper interception for the reboot commands,
> it does the wrong things and needs to stay out of the way. Thanks!

Except that right now (systemd-187-3.fc18.x86_64, polkit-0.107-2.fc18.x86_64) the userhelper authentication/authorization actually works:

> # two different users logged in
> $ /usr/sbin/reboot
>
> ** (process:764): CRITICAL **: polkit_agent_listener_initiate_authentication: assertion `identities != NULL' failed
Failed to issue method call: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
> Must be root.
/var/log/secure:
> Aug  6 10:11:31 rawhide polkitd[524]: Operator of unix-process:763:17463 FAILED to authenticate to gain authorization for action org.freedesktop.login1.reboot for unix-process:763:17463 [<unknown>] (owned by unix-user:mitr)

(when no password is required, the reboot proceeds normally, so it seems to be a problem with authentication.  )


Pretty please, let's have the new thing working before switching, OK?

(In reply to comment #6)
> (In reply to comment #5)
> > Please entirely drop the consolehelper interception for the reboot commands,
> > it does the wrong things and needs to stay out of the way. Thanks!
> 
> Except that right now (systemd-187-3.fc18.x86_64,
> polkit-0.107-2.fc18.x86_64) the userhelper authentication/authorization
> actually works:
> 
> > # two different users logged in
> > $ /usr/sbin/reboot
> >
> > ** (process:764): CRITICAL **: polkit_agent_listener_initiate_authentication: assertion `identities != NULL' failed
> Failed to issue method call: Did not receive a reply. Possible causes
> include: the remote application did not send a reply, the message bus
> security policy blocked the reply, the reply timeout expired, or the network
> connection was broken.

I've seen problems like this because a) selinux was in enforcing mode [1]; or b) installation of 0.107 mystically failed to created the polkitd user (see bug 841451).

[1] : Yes, asking people to put selinux in permissive mode is not ideal. But I don't control the selinux policy for my software (or this broken development model) so I'm not the right person to shout at

(In reply to comment #7)
> I've seen problems like this because a) selinux was in enforcing mode [1];
Yes, it was in enforcing mode.

> or b) installation of 0.107 mystically failed to created the polkitd user
> (see bug 841451).
That happened as well, but I have noticed and (I think I) fixed that manually - or at least (rpm -V polkit) didn't report anything.

> [1] : Yes, asking people to put selinux in permissive mode is not ideal. But
> I don't control the selinux policy for my software (or this broken
> development model) so I'm not the right person to shout at

Well...  Given this minimal information I don't think I can contribute to fixing the problem, so for now I'll hope that you and the selinux-policy maintainers can work it out.  http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria suggests that SELinux does need to work, eventually.

(In reply to comment #8)
> (In reply to comment #7)
> > I've seen problems like this because a) selinux was in enforcing mode [1];
> Yes, it was in enforcing mode.

Well, did putting the system in permissive mode fix the problem or not?

> > or b) installation of 0.107 mystically failed to created the polkitd user
> > (see bug 841451).
> That happened as well, but I have noticed and (I think I) fixed that
> manually - or at least (rpm -V polkit) didn't report anything.
> 
> > [1] : Yes, asking people to put selinux in permissive mode is not ideal. But
> > I don't control the selinux policy for my software (or this broken
> > development model) so I'm not the right person to shout at
> 
> Well...  Given this minimal information I don't think I can contribute to
> fixing the problem, so for now I'll hope that you and the selinux-policy
> maintainers can work it out. 
> http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria suggests that
> SELinux does need to work, eventually.

Sure, I'm just saying that any selinux policy is totally out of my control [1]. Of course I work with the selinux guys as much as I can but, really, at the end of the day it's up to them to fix any problems.

[1] : I'm also saying that it's totally broken that things are this way. I've also complained loudly about this model in the past but no-one listens and nothing happens. So I just stopped complaining

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > I've seen problems like this because a) selinux was in enforcing mode [1];
> > Yes, it was in enforcing mode.
> 
> Well, did putting the system in permissive mode fix the problem or not?

Sorry, I have deleted that testing VM already, so I can't quickly check.

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > I've seen problems like this because a) selinux was in enforcing mode [1];
> > > Yes, it was in enforcing mode.
> > 
> > Well, did putting the system in permissive mode fix the problem or not?
> 
> Sorry, I have deleted that testing VM already, so I can't quickly check.

Well, that's just great. I guess we can ignore comment 6 then.

Here's a request: next time you think you've find a bug and you want to help with debugging, always try to see if it works in permissive mode. If it does, then you should file the bug against selinux-policy instead of complaining about the wrong component. Thanks.

(In reply to comment #6)

> Pretty please, ...

The real prettyness starts only with the consolehelper stuff out of the way. :)

Please remove it, we will fix anything in a timely manner if needed.

Pretty as in "pretty broken software development model"? I mean - remove it, break this and that and maybe fix it later.

Anyway this change should be moved to rawhide.

*** Bug 843299 has been marked as a duplicate of this bug. ***

Again, please remove the stuff that breaks systemd, or let me know if you don't
have the time, and I will do it. Thanks!

(In reply to comment #15)
> Again, please remove the stuff that breaks systemd

"Breaks a newly introduced feature in systemd".

So far noone has contested the problem report from comment #6, so I assume it really is broken.

> let me know if you don't have the time

It's not a matter of time - userhelper provides some functionality and it's not reasonable to just break that functionality in exchange for providing a different one.  systemd maintainers can do that to their users if they want to, I don't want to do that to userhelper users.


I'll be on PTO next Mon-Wed, I currently plan to re-test the functionality from comment #6 next Thursday, and if it's still broken by then, I'll keep the VM for futher debugging around.

Please remove it or I will do it. I'm just tired of the problems usermode is
causing. The functionality has entirely moved to systemd, usermode has nothing
to provide regarding reboot in Fedora 18, so please fget it out of the way.

Thanks!

poweroff/reboot have the functionality of usermode anyway, and quite frankly the binaries in bin/ are just confusing and misleading. They must go. 

These consolehlper hookups should have lived in the packages providing poweroff/reboot anyway and not in consolehelper.rpm itself. Hence it's the right thing to delete them there anyway.

And uh, even if PK has bugs, these are of the fixable kind, not of the fundamental kind. It's no reason to clean this up now.

Created attachment 603139 [details]
Proposed patch

These removes all traces of the halt/poweroff/reboot/shutdown logic from the RPM. Please commit this (or something equivalent).

(In reply to comment #16)
> (In reply to comment #15)
> > Again, please remove the stuff that breaks systemd
> 
> "Breaks a newly introduced feature in systemd".
> 
> So far noone has contested the problem report from comment #6, so I assume
> it really is broken.

Total utter non-sense to make such an assumption:

 1. you didn't test with selinux in non-enforcing mode (requested in comment 7 and comment 9)

 2. you threw away the VM and didn't install a new one to try again .. really?

As for 1: if you have experience with developing the OS using tip-of-tree software you really should know that the selinux policy is not going to be accurate (because it's all centralized). So you should always try with non-enforcing policy if something is not working (and then look at AVC's and file bugs against selinux-policy if you get any).

As for 2, that's just mind-boggling. The fact you didn't reinstall the VM to answer the questions in comment 7 or comment 9 ... that's just annoying especially since I personally spent time trying to help you. I had expected more from you.

Therefore, it is very had to take your comment seriously.

Tested today:

[notting@nostromo: ~]$ ssh foo.redhat.com
Warning: Permanently added 'wierzbowski.devel.redhat.com,10.11.228.26' (RSA) to the list of known hosts.
foo.redhat.com's password: 
Last login: Mon Aug 20 14:45:56 2012 from nostromo.devel.redhat.com
[foo@weirzbowski ~]$ reboot 
==== AUTHENTICATING FOR org.freedesktop.login1.reboot ===
Authentication is required for rebooting the system.
Authenticating as: Foo Bar (foo)
Password: 
==== AUTHENTICATION COMPLETE ===

Seems to be working for me, albeit with more noise than is strictly necessary.

Can we please remove these links from usermode?

(In reply to comment #22)
> Tested today:
> 
> [notting@nostromo: ~]$ ssh foo.redhat.com
> Warning: Permanently added 'wierzbowski.devel.redhat.com,10.11.228.26' (RSA)
> to the list of known hosts.
> foo.redhat.com's password: 
> Last login: Mon Aug 20 14:45:56 2012 from nostromo.devel.redhat.com
> [foo@weirzbowski ~]$ reboot 
> ==== AUTHENTICATING FOR org.freedesktop.login1.reboot ===
> Authentication is required for rebooting the system.
> Authenticating as: Foo Bar (foo)
> Password: 
> ==== AUTHENTICATION COMPLETE ===
> 
> Seems to be working for me, albeit with more noise than is strictly
> necessary.
> 
> Can we please remove these links from usermode?

/me aborts his VM installation.

Thanks a lot, removing now.

usermode-1.110-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/usermode-1.110-1.fc18

Built in F18 and rawhide usermode-1.110-1.fc18.

Do you want to handle the Fedora release notes for this, or should I do it?

Package usermode-1.110-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing usermode-1.110-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-12336/usermode-1.110-1.fc18
then log in and leave karma (feedback).

(In reply to comment #25)
> Built in F18 and rawhide usermode-1.110-1.fc18.
> 
> Do you want to handle the Fedora release notes for this, or should I do it?

Added to https://fedoraproject.org/wiki/Documentation_Security_Beat .

usermode-1.110-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

In general this works, using the reboot command, but reboot -f now displays: Must be root