Bug 803007

Summary: Network applet and apper stop working after upgrade from OpenSuse 12.2
Product: [openSUSE] openSUSE 12.3 Reporter: Forgotten User qidzN81um_ <forgotten_qidzN81um_>
Component: SecurityAssignee: systemd maintainers <systemd-maintainers>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None CC: jslaby, kukuk, thomas.blume
Version: RC 1   
Target Milestone: ---   
Hardware: All   
OS: openSUSE 12.3   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Forgotten User qidzN81um_ 2013-02-10 21:51:55 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0

Network applet and apper stopped working after upgrade from OpenSuse 12.2. In case of apper, I get a list of updates, but the installation is refused with a remark of insuffient rights. The network applet claims that the network manager is not running, although the latter is well running. I figured out that the problems are caused by console kit reporting (via ck-list-sessions)) that my session is not-local and not active.
The error shows same symptoms as bug 790222.

Since I needed my system back working quickly, I made a clean install instead of the previous upgrade and everything worked. I then realized that the console-kit is not used any more by default. I don't know why it was used on my 12.2 system (which -I think- was already an upgrade from 12.1), but it worked fine before.
=> the upgrade should check and eventually de-install console-kit (or properly reconfigure it)

Reproducible: Always

Steps to Reproduce:
1. Upgrade from 12.2 with user console kit for session authorization
2. try to user-defined open a network connection
3.
Actual Results:  
claims network manager not running

Expected Results:  
working connection
(or at least a suitable error message indicating that insufficient rights cause this claim).
Comment 1 Jiri Slaby 2013-03-01 22:46:42 UTC
I had the same issue. At least I think. My loginctl output was empty (no seats). I had to add pam_systemd to common-session:
session required        pam_limits.so
session required        pam_unix.so     try_first_pass
session required        pam_systemd.so
session optional        pam_umask.so
session optional        pam_env.so

Now everything works for me.
Comment 2 Frederic Crozat 2013-03-05 10:28:13 UTC
/etc/pam.d/common-session should be a symlink to /etc/pam.d/common-session-pc (ie the file will be under pam-config control and should get pam_systemd.so added automatically).

Is it the case ?
Comment 3 Jiri Slaby 2013-03-06 10:11:26 UTC
(In reply to comment #2)
> /etc/pam.d/common-session should be a symlink to /etc/pam.d/common-session-pc
> (ie the file will be under pam-config control and should get pam_systemd.so
> added automatically).
> 
> Is it the case ?

Nope, both were self-standing files. Now I fixed it so that common-* point to common-*-pc. And of course -pc contained pam_systemd.so. I have no idea how I come to that situation...
Comment 4 Frederic Crozat 2013-03-06 10:26:37 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > /etc/pam.d/common-session should be a symlink to /etc/pam.d/common-session-pc
> > (ie the file will be under pam-config control and should get pam_systemd.so
> > added automatically).
> > 
> > Is it the case ?
> 
> Nope, both were self-standing files. Now I fixed it so that common-* point to
> common-*-pc. And of course -pc contained pam_systemd.so. I have no idea how I
> come to that situation...

I was afraid of that. rpm can screw the symlink (I remember reports of this but I'm not sure it was already reported in bugzilla), since it is not stored as such for pam package..

Reassigning to mls but adding throsten as cc.
Comment 5 Thorsten Kukuk 2013-03-06 10:31:07 UTC
Has nothing to do with RPM. Somebody played with pam-config or modified files and afterwards ignored the pam-config warnings that pam-config is now disabled.
Comment 6 Michael Schröder 2013-03-06 10:33:05 UTC
Thanks Thorsten, reassigned back to Frederic.
Comment 7 Frederic Crozat 2013-03-06 10:42:26 UTC
(In reply to comment #5)
> Has nothing to do with RPM. Somebody played with pam-config or modified files
> and afterwards ignored the pam-config warnings that pam-config is now disabled.

Well, I'm 99% sure I already saw reports on IRC with similar issue where common-session was handled by pam-config and after upgrade (to Factory), it wasn't a symlink anymore. And it is not systemd, since systemd only relies on pam-config.

It would be interesting to know if there was a common-session.rpmsave or common-session.rpmnew created..
Comment 8 Jiri Slaby 2013-03-06 10:44:02 UTC
There was .rpmnew, but that seemed to be old (mid 2012, much older than common-session), so I removed that.
Comment 9 Thomas Blume 2015-02-27 10:39:32 UTC
(In reply to Frederic Crozat from comment #7)
> 
> Well, I'm 99% sure I already saw reports on IRC with similar issue where
> common-session was handled by pam-config and after upgrade (to Factory), it
> wasn't a symlink anymore. And it is not systemd, since systemd only relies
> on pam-config.
> 

https://forums.opensuse.org/showthread.php/491766-Authorization-failed

Actually, this is a duplicate of bnc#812462.
-> closing

*** This bug has been marked as a duplicate of bug 812462 ***