Red Hat Bugzilla – Full Text Bug Listing
|Summary:||LXDM and nm-applet|
|Product:||[Fedora] Fedora||Reporter:||clepper <christian.lepper>|
|Component:||lxdm||Assignee:||Christoph Wickert <cwickert>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||lxdm-0.2.0-4.fc12||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-06-01 14:22:31 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description clepper 2010-03-12 03:59:03 EST
Created attachment 399587 [details] context of Description of problem: When using LXDM as Login-Manager, nm-applet will not start. When trying to start it manually from console, it returns ** (nm-applet:2909): WARNING **: <WARN> request_name(): Could not acquire the NetworkManagerUserSettings service. Error: (9) Connection ":1.70" is not allowed to own the service "org.freedesktop.NetworkManagerUserSettings" due to security policies in the configuration file when using GDM or KDM, nm-applet will start without problem. nm-manager is running, as the preferred wireless network is actually activated. Version-Release number of selected component (if applicable): lxdm-0.1.1-0.2.20100303gite4f7b39.fc11.i586 from update selinux-policy-3.6.12-95.fc11.noarch How reproducible: Use LXDM, try to start nm-applet Steps to Reproduce: 1. change Login-manager to LXDM via /etc/sysconfig/desktop 2. login as normal user 3. Actual results: nm-applet will not start, with above error message Expected results: nm-applet should start Additional info: after reading #553622 I checked the context of user processes after login. When using LXDM, all processes of the user run with a context of initrc_t. When using GDM the processus run as unconfined_t So this seems to be a selinux issue. I update selinux-policy to latest version available, rebooted with autorelabel, still the same behaviour.
Comment 1 Christoph Wickert 2010-03-15 12:07:20 EDT
Can you please check if your /etc/pam.d/lxdm is up to date or if there is a lxdm.rpmnew file instead? /etc/pam.d/lxdm should look like this: #%PAM-1.0 auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth required pam_succeed_if.so user != root quiet auth required pam_env.so auth substack system-auth auth optional pam_gnome_keyring.so account required pam_nologin.so account include system-auth password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session optional pam_gnome_keyring.so auto_start session include system-auth Does rpm -V lxdm return something?
Comment 2 clepper 2010-03-15 13:04:19 EDT
/etc/pam.d/lxdm is exactly as you describe. rpm -V lxdm gives S.5....T. c /etc/lxdm/lxdm.conf and ls -l /etc/lxdm -rw-r--r--. 1 root root 294 11. Mär 21:16 lxdm.conf -rw-r--r--. 1 root root 306 8. Feb 22:15 lxdm.conf.rpmsave -rwxr-xr-x. 1 root root 1154 28. Feb 15:53 Xsession in lxdm.conf.rpmsave I changed simply last_session=LXDE.desktop this shouldn't have anyeffect on the context, IMHO.
Comment 3 Christoph Wickert 2010-03-15 16:52:40 EDT
Right. On the other hand I don't see what could be wrong with the pam file. I have exactly the same file and I have no problems on Fedora 12.
Comment 4 clepper 2010-03-16 09:44:45 EDT
Might there be a difference in the PAM-stack between F12 et F11? My system is fc11, installed from the LXDE-live CD.
Comment 5 Christoph Wickert 2010-03-19 19:16:15 EDT
Huh? There is no F11 LXDE livecd.
Comment 6 clepper 2010-03-22 04:46:10 EDT
Well, I got one from here: http://alt.fedoraproject.org/pub/alt/remixes/LXDE/ And it was working nicely - as long as you use GDM :-(
Comment 7 Fedora Update System 2010-04-05 16:55:43 EDT
lxdm-0.2.0-0.1.20100405gitd65ce94.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/lxdm-0.2.0-0.1.20100405gitd65ce94.fc13
Comment 8 Fedora Update System 2010-04-05 16:56:53 EDT
lxdm-0.2.0-0.1.20100405gitd65ce94.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/lxdm-0.2.0-0.1.20100405gitd65ce94.fc12
Comment 9 Christoph Wickert 2010-04-05 18:02:15 EDT
This is fixed in the new version, but it wont build on F11 due to an outdated glibc version. I'm inclined to withdraw the F11 update and return to 0.1.0 as it is a stable version and it works. The update for F11 is not really necessary as the selinux issues are fixed in the latest policy. Or do I miss something?
Comment 10 Fedora Update System 2010-04-06 15:58:04 EDT
lxdm-0.2.0-0.2.20100405gitd65ce94.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lxdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lxdm-0.2.0-0.2.20100405gitd65ce94.fc13
Comment 11 Fedora Update System 2010-04-08 21:39:59 EDT
lxdm-0.2.0-0.2.20100405gitd65ce94.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lxdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lxdm-0.2.0-0.2.20100405gitd65ce94.fc12
Comment 12 clepper 2010-04-11 06:13:43 EDT
Well, I downgraded to 0.1.0, and nm-applet is still not starting. when I am trying to start manually, I get: cl@etienne:~> nm-applet ** (nm-applet:2629): WARNING **: <WARN> request_name(): Could not acquire the NetworkManagerUserSettings service. Error: (9) Connection ":1.29" is not allowed to own the service "org.freedesktop.NetworkManagerUserSettings" due to security policies in the configuration file So the fundamental problem persists for me, sadly. Additionally, the language selection on the login-screen is not working (the list stays blank) in this version, but this is a minor issue, which is resolved in 0.1.1 From all this, do I have to conclude that this bug will not be further resolved in fc11?
Comment 13 Bug Zapper 2010-04-28 07:57:14 EDT
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Fedora Update System 2010-05-21 21:45:22 EDT
lxdm-0.2.0-4.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lxdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lxdm-0.2.0-4.fc12
Comment 15 Fedora Update System 2010-06-01 14:22:06 EDT
lxdm-0.2.0-4.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.