Description of problem:
If i want to use xdm i have to disable SELinux (no good idea :-( )
Version-Release number of selected component (if applicable):
selinux-policy-targeted (Version: 3.0.8 Release: 53.fc8)
Steps to Reproduce:
1. Push the Power Button
2. Wait until xdm Login screen appears
3. Type in Name and Password and press ENTER
Login Screen appears again
start of xfce4
When I start xdm from root konsole it works
With setenforce 0 it works also
Created attachment 262301 [details]
messages copied from the setroubleshootbrowser
Could you verify that your system labeling is correct.
touch /.autorelabel; reboot
This looks like some kind of labeling problem.
Sorry. This didn't help. It's still the same.
I suppose, you can reproduce the problem yourself.
Just install xorg-x11-xdm, change the 1st line of /etc/sysconfig/desktop
to DISPLAYMANAGER="XDM" and adore the problem :-)
Ok I misread the message. The problem is that /etc/pam.d/xdm does not have
pam_selinux in it. It should look something like /etc/pam.d/gdm
auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
auth required pam_env.so
auth include 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 include system-auth
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
So uh, this is from late 2007, is this fixed yet?
Sorry. I deleted F8 from the partition, because i couldn't use it with the bug
and it seemed the nobody will fix it :-( So could please somebody else test if
it works now ?! The bug should be reproducible for everybody...
Hopefully F9 is usable for me :-)
This is still not fixed.
Setting NEEDINFO for developer is one of the most secure ways how to make bug lost.
*** Bug 455584 has been marked as a duplicate of this bug. ***
Please change the Distribution field of this bug to "Fedora 9" so that it does not get lost when F8 is EOL'd.
I have verified that on a freshly installed and updated F9/x86_64 system, xdm runs the user session under the system_u:system_r:xdm_t context, making the default GNOME session fail. With "setenforce 0" it works, but spits out lots of AVCs.
I am stuck with xdm, because gdm is still unusable in F9: for example, there is no way to handle a multi-seat desktop in gdm (at least since two weeks ago there has been a gdm version which can actually do XDMCP :-| ).
Created attachment 321791 [details]
suggested patch against CVS devel repo
I just updated the xdm pam.d file in rawhide.
Jan, if you can verify that just
cp /etc/pam.d/gdm /etc/pam.d/xdm
makes it work in F9, I'll update it.
Re: comment #12
I have tried it and it did not work. I have to create a config file as in
comment #11 (Matej's patch), i.e. to add a following line after the pam_selinux_permit.so line in the "auth" section:
auth required pam_succeed_if.so user != root quiet
With this one line difference against /etc/pam.d/gdm, I am now able to log in using xdm on both heads/seats.
HOWEVER: there is still some problem with setting file permissions - the usual device files (/dev/snd/*, /dev/video*, /dev/sr0, etc.) do not get a new ACL entry allowing the logged-in user to access them. Moreover, even when I chmod a+rw /dev/sr0, the permissions are reset back to root:disk 0660 as soon as the new media is inserted to the drive, making the DVD drive unusable for the logged in user.
So probably there is still a problem with XDM versus ConsoleKit/PolicyKit/HAL.
Should I open a new bug for it or will we continue in this one?
(In reply to comment #13)
> HOWEVER: there is still some problem with setting file permissions - the usual
> device files (/dev/snd/*, /dev/video*, /dev/sr0, etc.) do not get a new ACL
This has nothing to do with this bug (because these things are done by SELinux), and it is perfect duplicate of bug 237621.
(In reply to comment #13)
> Re: comment #12
> I have tried it and it did not work. I have to create a config file as in
> comment #11 (Matej's patch), i.e. to add a following line after the
> pam_selinux_permit.so line in the "auth" section:
> auth required pam_succeed_if.so user != root quiet
> With this one line difference against /etc/pam.d/gdm, I am now able to log in
> using xdm on both heads/seats.
But this line should just disable root login in xdm and it should not affect the rest of the pam stack.
Perhaps you have something broken in /etc/pam.d/system-auth?
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
xdm tries to create X auth files in /etc/X11/xdm by default. This is wrong, and SELinux will prevent xdm to do wrong thing. Right place for these stuff is /var/lib/xdm. This patch helped me to run both xdm and selinux. Also package xorg-x11-xdm needs to create this dir during package install.
--- /etc/X11/xdm/xdm-config.orig 2009-01-22 21:12:06.000000000 +0100
+++ /etc/X11/xdm/xdm-config 2009-01-22 21:11:53.000000000 +0100
@@ -11,6 +11,7 @@
Created attachment 330015 [details]
patch adding XDMXAUTHDIR variable
Proposed fixing xdm-config.
Testing scratch builds are at
http://koji.fedoraproject.org/scratch/mcepl/task_1083646/ (for Rawhide)
http://koji.fedoraproject.org/scratch/mcepl/task_1083651/ (for Fedora 10)
Please test and let me know, whether it works.
Works for me on F10/x86-64.
Rawhide package works fine as well.
xorg-x11-xdm-1.1.6-7.fc10 has been submitted as an update for Fedora 10.
xorg-x11-xdm-1.1.6-7.fc10 has been pushed to the Fedora 10 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 xorg-x11-xdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2695
xorg-x11-xdm-1.1.6-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.