Bug 769531

Summary: pkexec crashes X session
Product: [openSUSE] openSUSE 12.2 Reporter: Dominique Leuenberger <dimstar>
Component: BasesystemAssignee: Frederic Crozat <fcrozat>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P5 - None CC: aj, badshah400, damianatorrpm, fcrozat, ismail, kukuk
Version: Factory   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: /var/log/messages
messages - for another failure
dmesg output with lots of systemd debug...

Description Dominique Leuenberger 2012-06-30 12:25:57 UTC
A simple invocation of
  pkexec /sbin/yast2
resets the X-session, thus rendering pkexec entirely unusable.

So far I did not find any hints for the crash in /var/log/Xorg.0.log(.old), .xsession-errors or /var/log/messages (which is a bit weird...)
Comment 1 Dominique Leuenberger 2012-07-02 22:29:55 UTC
I actually just see that this is also the cause for another issue I've seen lately:

when on Battery, and the notebook is not touched for a while, the 'screen dim' would kick in... in this moment, though, X resets...

in /var/log/messages, you can find:

Jul  3 00:20:51 laran pkexec[9674]: dle1gis: Executing command [USER=root] [TTY=unknown] [CWD=/home/dle1gis] [COMMAND=/usr/lib/gnome-settings-daemon-3.0/gsd-backlight
-helper --set-brightness 4]
Comment 2 Vincent Untz 2012-07-03 18:19:22 UTC
I'm pretty sure this is recent, and given the lack of changes in polkit since February (if we except the packaging fix a few weeks ago), I doubt that polkit itself is the root cause.

In the past, such issues were either caused by bugs in the pam module from systemd (iirc) and/or glibc bugs.

Andreas: how did people find the cause of previous issues? Was there some specific log file that helped?
Comment 3 Andreas Jaeger 2012-07-03 20:07:33 UTC
I don't remember how people figured it out.

For this case, I would look at 
* dmesg output: you should see a message like:
[23634.779115] packagekitd[538]: segfault at e6a88 ip 00007fc42c051938 sp 00007fc427768ae0 error 6 in libzypp.so.1003.1.5[7fc42bc61000+4ca000]

And this show which program is killed.

* attach gdb to the X server before running pkexec and check the backtrace.

Let's add Frederic since this really looks similar to our pam/systemd issue - and I've CC'ed myself to check glibc as well ;)

Dominique, we need more debugging from you.
Comment 4 Andreas Jaeger 2012-07-04 07:21:27 UTC
Dominique, what's the output of "grep systemd /etc/pam.d/*" ?

Btw. I just tried to run "pkexec /sbin/yast2" on my i686 system from the gnome-terminal, was asked for the root password and had a ncurses yast running afterwards. So, no problems on that system.
Comment 5 Frederic Crozat 2012-07-04 09:00:07 UTC
to get more debug info, try to boot with "systemd.log_level=debug systemd.log_target=kmsg" + add "debug=1" to pam_systemd line in /etc/pam.d/common-session

and when it crashes, check dmesg and /var/log/messages
Comment 6 Dominique Leuenberger 2012-07-04 16:22:10 UTC
(In reply to comment #4)
> Dominique, what's the output of "grep systemd /etc/pam.d/*" ?

/etc/pam.d/common-session:session	optional	pam_systemd.so
/etc/pam.d/common-session-pc:session	optional	pam_systemd.so
Comment 7 Dominique Leuenberger 2012-07-04 16:27:43 UTC
(In reply to comment #5)
> to get more debug info, try to boot with "systemd.log_level=debug
> systemd.log_target=kmsg" + add "debug=1" to pam_systemd line in
> /etc/pam.d/common-session
> 
> and when it crashes, check dmesg and /var/log/messages

How great is that! Simply adding debug=1 to pam_systemd.so in common-session is sufficient to not trigger the crash.
Comment 8 Andreas Jaeger 2012-07-04 19:08:57 UTC
Can you still reproduce it if you remove the debug=1 line? Might be a Heisenbug. ;-(

I could only trigger it once - with a broken pam config.

The contents from comment#6 looks fine.

Frederic, will you take the bug? Or whom shall we blame? ;)
Comment 9 Dominique Leuenberger 2012-07-04 20:16:07 UTC
No, currently I can't reproduce it...

all what I actually did was:
modified /etc/pam.d/common-session and added debug=1 to the line with pam_systemd.so...

saved, logged out, back in (to enable the new 'session').
pkexec no longer crashes...

removed the debug=1 again from the file... logged out / back in.. no crash.. reboot.. still not crash...

so yes, 'on my system' it is apparently solved... but should we trust it? Really not sure what to say now..

I'll monitor it a bit more.. the most common 'way' it happened for me was while being on battery, leaving the system untouched for a while, then the screen dim kicks in (ising pkexec) and it brought me back to gdm.
Comment 10 Frederic Crozat 2012-07-05 07:47:48 UTC
I'd suggest to let debug=1, in the case it crashes in the future.

If it is similar to previous "sudo / pam_systemd" bug, it might happens only after several pkexec calls or maybe when calling sudo (or su) and then pkexec (but I'm just guessing)
Comment 11 Andreas Jaeger 2012-07-05 08:03:21 UTC
Just got locked out - Frederic, looks really like your bug, look at the the pkexec invocations below, I'm attaching a bit more of the log file.

Jul  5 09:52:35 byrd pkexec: pam_systemd(polkit-1:session): Asking logind to create session: uid=659 pid=28721 service=polkit-1 type=unspecified seat= vtnr=0 tty= display= remote=no remote_user= remote_host=
Jul  5 09:52:35 byrd pkexec: pam_systemd(polkit-1:session): Failed to create session: No such file or directory
Jul  5 09:52:36 byrd pkexec[28721]: aj: Executing command [USER=root] [TTY=/dev/pts/10] [CWD=/home/aj/build/osc-branches/home:a_jaeger:devel-glibc/glibc] [COMMAND=/sbin/yast2]
Jul  5 09:56:15 byrd dbus-daemon[698]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
Jul  5 09:56:15 byrd dbus-daemon[698]: helper(pid 28866): launched job udisks-helper-ata-smart-collect on /dev/sda
Jul  5 09:56:15 byrd dbus-daemon[698]: **** Refreshing ATA SMART data for /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb
Jul  5 09:56:15 byrd dbus-daemon[698]: helper(pid 28867): launched job udisks-helper-ata-smart-collect on /dev/sdb
Jul  5 09:56:15 byrd dbus-daemon[698]: helper(pid 28867): completed with exit code 0
Jul  5 09:56:15 byrd dbus-daemon[698]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb
Jul  5 09:56:15 byrd dbus-daemon[698]: helper(pid 28866): completed with exit code 0
Jul  5 09:56:15 byrd dbus-daemon[698]: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
Jul  5 09:57:29 byrd polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session1 successfully authenticated as unix-user:root to gain ONE-SHOT authorization for action org.freedesktop.policykit.exec for unix-process:5242:11258 [/bin/bash] (owned by unix-user:aj)
Jul  5 09:57:29 byrd pkexec: pam_systemd(polkit-1:session): Asking logind to create session: uid=659 pid=28928 service=polkit-1 type=unspecified seat= vtnr=0 tty= display= remote=no remote_user= remote_host=
Jul  5 09:57:29 byrd pkexec: pam_systemd(polkit-1:session): Reply from logind: id=1 object_path=/org/freedesktop/login1/session/1 runtime_path=/run/user/aj session_fd=10 seat=seat0 vtnr=7
Jul  5 09:57:29 byrd pkexec[28928]: aj: Executing command [USER=root] [TTY=/dev/pts/11] [CWD=/home/aj/build/glibc/testing] [COMMAND=/sbin/yast2]
Jul  5 09:57:29 byrd systemd-logind[16194]: Removed session 1.
Jul  5 09:57:29 byrd kdm: :0[4587]: pam_systemd(xdm:session): Failed to release session: No such file or directory
Jul  5 09:57:30 byrd kdm: :0[4587]: pam_close_session() failed: Cannot make/remove an entry for the specified session
Comment 12 Andreas Jaeger 2012-07-05 08:04:40 UTC
Created attachment 497471 [details]
/var/log/messages
Comment 13 Andreas Jaeger 2012-07-05 08:11:10 UTC
Created attachment 497472 [details]
messages - for another failure

This time it I got kicked out directly after log in.
Comment 14 Andreas Jaeger 2012-07-05 08:11:33 UTC
Created attachment 497474 [details]
dmesg output with lots of systemd debug...
Comment 15 Frederic Crozat 2012-07-05 15:05:53 UTC
I've been able to reproduce the issue by using this test scenario (works in a text tty or a graphical session):
- login
- run "sudo /bin/ls" or "su -c /bin/ls"
- run "pkexec /bin/ls"
=> logout

it is probably caused by pam_systemd being called in sudo / su (due to their pam configuration calling common-session pam configuration).

Fedora is making sure to not include common-session in their sudo / su configuration. I wonder if we should do the same (because there is no new audit session created when running su / sudo and logind is relying on those audit session to "terminate" or not a session, when exiting) ?
Comment 16 Andreas Jaeger 2012-07-06 07:49:58 UTC
Let's include Thorsten to help with pam configuration (Thorsten see comment #15).
Comment 17 Thorsten Kukuk 2012-07-06 07:55:19 UTC
common-session is important for su/sudo, especially if you don't want to manually sync all changes to the su/sudo config files.

If, then the bug is that pam_systemd cannot be called from everything and should not be added to common-session.
Comment 18 Frederic Crozat 2012-07-06 08:20:50 UTC
ok, let me see how to change the pam-config patch I wrote for systemd long time ago so it write the change in specific pam configuration (not ideal, because it will require to have a list somewhere).

Or I try to patch pam_systemd to "detect" su/sudo and not do anything in this particular case (not pretty either).
Comment 19 Bernhard Wiedemann 2012-07-13 17:00:20 UTC
This is an autogenerated message for OBS integration:
This bug (769531) was mentioned in
https://build.opensuse.org/request/show/127853 Factory / systemd
Comment 20 Ivanov 2012-08-22 08:36:57 UTC
Hi,

I tried to rebuild the systemd package with the login-logout patch enabled, it build successfully, I installed it and have no issues with pkexec. 

Is there any way I can get the automatic multiseat support working with 12.2?

Cheers,
Damian
Comment 21 Frederic Crozat 2012-08-22 09:28:37 UTC
no, I won't enable this patch for 12.2 (it is not in Fedora17 either). And this patch is orthogonal to multiseat (which this bug is not about).
Comment 22 Ismail Dönmez 2012-08-23 08:35:50 UTC
Closing as fixed then.