Bug 789068

Summary: systemd-inhibit: permission denied
Product: [openSUSE] openSUSE Tumbleweed Reporter: Stefan Seyfried <seife>
Component: BasesystemAssignee: Frederic Crozat <fcrozat>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P5 - None CC: coolo, forgotten_cAXlJ_FoSf, forgotten_PoQ9LLo9Cj, jdd, jrswagswegie1996, koenig, lnussel, meissner, security-team, suse-beta
Version: 13.1 Beta 1   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Third Party Developer/Partner Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Stefan Seyfried 2012-11-09 18:27:23 UTC
Trying to work around https://bugzilla.novell.com/show_bug.cgi?id=789057, I tried to use systemd-inhibit, but it does not work:

seife@susi:~> systemd-inhibit --what="handle-lid-switch" sleep 100
Failed to issue method call: Access denied
Failed to inhibit: Unknown error -1

So I can't even "fix" the non-broken xfce4-power-manager.
Comment 1 Stefan Seyfried 2012-11-19 09:17:55 UTC
After todays update to factory, this now works.
Comment 2 Stefan Seyfried 2013-02-25 18:22:46 UTC
After today's update to Factory, this bug is back again:

seife@susi:~> systemd-inhibit true
Failed to issue method call: Access denied
Failed to inhibit: Unknown error -1

But I can still list inhibitors:
seife@susi:~> systemd-inhibit --list
WHAT     WHO         WHY          MODE     UID    PID
sleep    root        inhibited    delay      0    921

1 inhibitors listed.
seife@susi:~> systemd-loginctl |cat
         3          0 root             seat0           
         4      10329 seife            seat0           
seife@susi:~> 

root is allowed to inhibit:

susi:~ # systemd-inhibit true
susi:~ #
Comment 3 Frederic Crozat 2013-02-26 10:57:05 UTC
there has been polkit-default-privs update. Might be related ?
Comment 4 Marcus Meissner 2013-02-26 12:15:58 UTC
yes, we reintroduced the permission handling.

rpm -q --changelog polkit-default-privs|head 

its probably needs to be a bit more relaxed.

(bug 783897  for the new systemd privileges)
Comment 5 Marcus Meissner 2013-02-26 13:51:34 UTC
Seife, can you briefly explain what systemd-inhibit actually does / the concept?

It is a biot hard to understand for me
Comment 6 Frederic Crozat 2013-02-26 14:01:50 UTC
Let me explain :

systemd is now taking care of hibernate / suspend and respond to lid switch, detect if system is idle (to autosuspend, for instance) (through logind). This new API allows applications to inhibit suspend / hibernate (when you watch a movie or do an upgrade). It can either be used through D-Bus or through systemd-inhibit, for applications / desktop environment which haven't been yet ported to the new D-Bus interface.
Comment 7 Frederic Crozat 2013-02-26 14:02:40 UTC
more info in man systemd-inhibit and http://www.freedesktop.org/wiki/Software/systemd/inhibit
Comment 8 Forgotten User cAXlJ_FoSf 2013-02-26 23:16:52 UTC
*** Bug 806348 has been marked as a duplicate of this bug. ***
Comment 9 Forgotten User cAXlJ_FoSf 2013-02-27 07:46:41 UTC
@Ludwig/Marcus:

Can you please push the fixed package to Factory and 12.3 ASAP, it is currently not possible to log into an Xfce desktop because of this bug.
Comment 10 Ludwig Nussel 2013-02-27 07:55:33 UTC
Well, if you cannot login because of that it's a bug in xfce. It must be prepared to receive a reply other than "yes" from polkit. Otherwise it doesn't make any sense to use polkit at all.
Comment 11 Ludwig Nussel 2013-02-27 10:57:04 UTC
AFAICT not beeing able to log into xfce is unreated to polkit. To verify just rm /etc/polkit-1/rules.d/50-default-privs.rules
Comment 12 Forgotten User cAXlJ_FoSf 2013-02-27 12:09:19 UTC
(In reply to comment #10)
> Well, if you cannot login because of that it's a bug in xfce. It must be
> prepared to receive a reply other than "yes" from polkit. Otherwise it doesn't
> make any sense to use polkit at all.

That's not possible because it doesn't use polkit directly, the xfce session wrapper script wraps the whole session with systemd-inhibit which isn't working any more in order to work around systemd's retarded handling of suspend/hibernate (see bnc#789057). I have a fix to get rid of this but it needs some more testing.

(In reply to comment #11)
> AFAICT not beeing able to log into xfce is unreated to polkit. To verify just
> rm /etc/polkit-1/rules.d/50-default-privs.rules

I'll triage later, however the polkit-default-privs from Base:System fixed the problem for me yesterday, ie. systemd-inhibit wasn't complaining about access denied any more.
Comment 13 Ludwig Nussel 2013-02-27 12:19:05 UTC
ah, now I get it. So what's missing is something like a --continue-anyways option to systemd-inhibit so it doesn't fail if it can't acquire the inhibit lock.
Comment 14 Forgotten User cAXlJ_FoSf 2013-02-27 12:27:00 UTC
(In reply to comment #13)
> ah, now I get it. So what's missing is something like a --continue-anyways
> option to systemd-inhibit so it doesn't fail if it can't acquire the inhibit
> lock.

Yes, since it is a wrapper it is otherwise impossible to get right in a race-free way. However, this will soon be obsolete in the xfce session wrapper script but I don't know if it will be in time for 12.3 GA or afterwards in a maintenance update.
Comment 15 Harald Koenig 2013-02-27 23:47:51 UTC
*** Bug 806603 has been marked as a duplicate of this bug. ***
Comment 16 Harald Koenig 2013-02-27 23:55:05 UTC
(In reply to comment #11)
> AFAICT not beeing able to log into xfce is unreated to polkit. To verify just
> rm /etc/polkit-1/rules.d/50-default-privs.rules

ACK! 
now systemd-inhibit works, and xfce4 login is possible again...
Comment 17 Jiří Suchomel 2013-02-28 08:42:02 UTC
*** Bug 804502 has been marked as a duplicate of this bug. ***
Comment 18 Harald Koenig 2013-03-01 11:04:52 UTC
YFYI: with polkit-0.110-2.2.1.x86_64 update, XFCE4 works again, with existing /etc/polkit-1/rules.d/50-default-privs.rules

thanks!
Comment 19 Stephan Kulow 2013-03-03 07:51:42 UTC
it's in 12.3
Comment 20 Forgotten User cAXlJ_FoSf 2013-03-07 09:42:13 UTC
*** Bug 807174 has been marked as a duplicate of this bug. ***