This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 499183

Summary: freenx-server script creates /tmp/.X11-unix without a valid SELinux context
Product: [Fedora] Fedora Reporter: Jeff Layton <jlayton>
Component: freenx-serverAssignee: Axel Thimm <axel.thimm>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 11CC: armandsl, axel.thimm, czml1, dev, dwalsh, dzrudy, eric.tanguy, jdennis, kevin, limburgher, matt.castelein, meiner, mgrepl, rc040203, rstrode, steved, tomastrnka, walters
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: freenx-server-0.7.3-18.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-11 02:19:12 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 549429    
Attachments:
Description Flags
Patch to fix context on /tmp/.X11-unix none

Description Jeff Layton 2009-05-05 10:51:32 EDT
On my up to date F11 machine, the setroubleshoot gui won't start. When I run:

$ sealert -b

...nothing happens, and I get these messages in the logs:

May  5 10:50:19 tleilax setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.124:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
May  5 10:50:19 tleilax setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.124 was not provided by any .service files

...the ':1.124' looks a little suspicious, but I'm no expert on dbus.
Comment 1 Daniel Walsh 2009-05-05 11:09:25 EDT
It is working for me.

rpm -qa setroubleshoot\*
setroubleshoot-plugins-2.0.16-1.fc11.noarch
setroubleshoot-server-2.1.8-1.fc11.x86_64
setroubleshoot-debuginfo-2.1.7-1.fc11.x86_64
setroubleshoot-doc-2.1.8-1.fc11.x86_64
setroubleshoot-2.1.8-1.fc11.x86_64
Comment 2 Daniel Walsh 2009-05-05 11:09:52 EDT
Do you have the client installed?

setroubleshoot-2.1.8-1.fc11.x86_64
Comment 3 Jeff Layton 2009-05-05 11:18:57 EDT
Yep, the box is fully patched, AFAIK:

$ rpm -qa setroubleshoot\*
setroubleshoot-server-2.1.8-1.fc11.x86_64
setroubleshoot-plugins-2.0.16-1.fc11.noarch
setroubleshoot-2.1.8-1.fc11.x86_64
Comment 4 Daniel Walsh 2009-05-05 11:24:34 EDT
Works for me.

Did you just update to this?  Have you rebooted?

I think you need to restart the messagebus
Comment 5 Jeff Layton 2009-05-05 12:30:07 EDT
No, I patched a couple of days ago and have rebooted since. I went ahead and rebooted to make sure though, but it doesn't seem to have made any difference. After rebooting, it still doesn't start:

May  5 12:26:41 tleilax setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.82:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
May  5 12:26:41 tleilax setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.82 was not provided by any .service files

...I should probably mention that this machine was upgraded from F10. Maybe something didn't go right there?
Comment 6 Daniel Walsh 2009-05-05 12:41:38 EDT
*** Bug 499218 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Walsh 2009-05-05 12:43:46 EDT
cat /usr/share/dbus-1/services/sealert.service
[D-BUS Service]
Name=org.fedoraproject.Setroubleshootd
Exec=/usr/bin/sealert -s
Comment 8 Jeff Layton 2009-05-05 12:49:33 EDT
Mine looks the same...

$ cat /usr/share/dbus-1/services/sealert.service
[D-BUS Service]
Name=org.fedoraproject.Setroubleshootd
Exec=/usr/bin/sealert -s

...my naive read is that the .service file looks correct, but the dbus request from the "client" is malformed (seems to have some extra characters prepended to it?)
Comment 9 Daniel Walsh 2009-05-05 12:57:09 EDT
Ray or Colin can you comment,  On the two F11 boxes I have this is working fine.
Comment 10 Ray Strode [halfline] 2009-05-05 15:35:47 EDT
Why is sealert taking the name Setroubleshootd (from comment 7)? Aren't sealert and setroubleshootd distinct?

> setroubleshoot: [dbus.proxies.ERROR] Introspect error
> on :1.82:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException:
> org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by
> message bus)

The above message makes me think that setroubleshoot is trying to get Introspection data from some other service and it's not replying and then timing out after the 15 second timeout or whatever it is.
Comment 11 Daniel Walsh 2009-05-05 15:55:52 EDT
Yes there is a session bus component and a system bus

sealert -b -> SESSION BUS-> sealert -s -> SYSTEM_BUS -> setroubleshoot

Meaning sealert -b activates the sealert -s service which activates the setroubleshoot service.
Comment 12 Bug Zapper 2009-06-09 11:10:59 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Dylan Graham 2009-09-30 00:43:54 EDT
Hi guys,
I think I have the same issue:

Sep 30 14:08:40 beef dbus: Rejected send message, 2 matched rules; type="method_call", sender=":1.33" (uid=500 pid=32449 comm="/usr/bin/python -E /usr/bin/sealert -s ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.34" (uid=0 pid=32451 comm="/usr/bin/python -E /usr/sbin/setroubleshootd -f  "))
Sep 30 14:08:40 beef setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.34:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.33" (uid=500 pid=32449 comm="/usr/bin/python -E /usr/bin/sealert -s ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.34" (uid=0 pid=32451 comm="/usr/bin/python -E /usr/sbin/setroubleshootd -f  "))
Sep 30 14:08:40 beef dbus: Rejected send message, 3 matched rules; type="method_call", sender=":1.33" (uid=500 pid=32449 comm="/usr/bin/python -E /usr/bin/sealert -s ") interface="org.fedoraproject.SetroubleshootdIface" member="start" error name="(unset)" requested_reply=0 destination=":1.34" (uid=0 pid=32451 comm="/usr/bin/python -E /usr/sbin/setroubleshootd -f  "))
Sep 30 14:08:40 beef setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched rules; type="method_call", sender=":1.33" (uid=500 pid=32449 comm="/usr/bin/python -E /usr/bin/sealert -s ") interface="org.fedoraproject.SetroubleshootdIface" member="start" error name="(unset)" requested_reply=0 destination=":1.34" (uid=0 pid=32451 comm="/usr/bin/python -E /usr/sbin/setroubleshootd -f  "))
Sep 30 14:08:40 beef dbus: Rejected send message, 3 matched rules; type="method_call", sender=":1.33" (uid=500 pid=32449 comm="/usr/bin/python -E /usr/bin/sealert -s ") interface="org.fedoraproject.SetroubleshootdIface" member="finish" error name="(unset)" requested_reply=0 destination=":1.34" (uid=0 pid=32451 comm="/usr/bin/python -E /usr/sbin/setroubleshootd -f  "))
Sep 30 14:08:40 beef setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.60:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
Sep 30 14:08:40 beef setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.60 was not provided by any .service files


[root@beef ~]# rpm -qa setroub*
setroubleshoot-server-2.1.14-3.fc11.x86_64
setroubleshoot-plugins-2.0.18-5.fc11.noarch
setroubleshoot-2.1.14-3.fc11.x86_64
Comment 15 Tomáš Trnka 2010-01-13 15:23:19 EST
Hello, I'm experiencing this bug together with bug #550013. Both of them have identical error messages (system DBus errors out with "rejected send message" and some derived errors) and both of them are caused by at_console="true" DBus policy rules (changing those to user= rules apparently works around both problems).
I've investigated this a bit and found that although the CK session is correctly registered (ck-list-sessions:
Session1:
        unix-user = '500'
        realname = 'Tomáš Trnka'
        seat = 'Seat1'
        session-type = ''
        active = TRUE
        x11-display = ':0'
        x11-display-device = '/dev/tty7'
        display-device = ''
        remote-host-name = ''
        is-local = TRUE
        on-since = '2010-01-13T19:24:47.527589Z'
        login-session-id = '4294967295'
),
there are no files in /var/run/console, which is where DBus looks to check whether the calling user is at the console. Simply running (as root)
touch /var/run/console/tootea (where "tootea" is my username) fixes both bugs.

I don't know which part of the system is responsible for creating this file, so feel free to reassign this bug appropriately.
Comment 16 Daniel Walsh 2010-01-13 15:30:55 EST
ls -lZ /var/run/console
Comment 17 Tomáš Trnka 2010-01-13 16:00:19 EST
[root@Bellatrix dbus-1.2.16]# ls -lZ /var/run/console
-rw-r--r--. root root unconfined_u:object_r:pam_var_console_t:s0 tootea

[root@Bellatrix dbus-1.2.16]# ls -ldZ /var/run/console
drwxr-xr-x. root root system_u:object_r:pam_var_console_t:s0 /var/run/console

Please note that no AVCs are reported and this bug appears in permissive mode too.
Comment 18 Tomáš Trnka 2010-01-13 16:31:56 EST
Digging deep into audit.log I've found this AVC, which used to happen on every logout, but it hasn't appeared since Wed Jan  6 09:52:11 2010 - approximately the time this bug started to appear. Perhaps this is an indication that the /var/run/console/tootea used to be created correctly until that time.


Summary:

SELinux is preventing /sbin/mount.crypt access to a leaked
/var/run/console/tootea (deleted) file descriptor.        

Detailed Description:

[umount.crypt has a permissive type (mount_t). This access was not denied.]

SELinux denied access requested by the umount.crypt command. It looks like this
is either a leaked descriptor or umount.crypt output was redirected to a file it
is not allowed to access. Leaks usually can be ignored since SELinux is just    
closing the leak and reporting the error. The application does not use the      
descriptor, so it will run properly. If this is a redirection, you will not get 
output in the /var/run/console/tootea (deleted). You should generate a bugzilla 
on selinux-policy, and it will get routed to the appropriate package. You can   
safely ignore this avc.                                                         

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385)           

Additional Information:

Source Context                system_u:system_r:mount_t:s0-s0:c0.c1023
Target Context                system_u:object_r:pam_var_console_t:s0  
Target Objects                /var/run/console/tootea (deleted) [ file ]
Source                        umount.crypt                              
Source Path                   /sbin/mount.crypt                         
Port                          <Unknown>                                 
Host                          <Unknown>                                 
Source RPM Packages           pam_mount-1.32-1.fc12                     
Target RPM Packages                                                     
Policy RPM                    selinux-policy-3.6.32-66.fc12             
Selinux Enabled               True                                      
Policy Type                   targeted                                  
Enforcing Mode                Enforcing                                 
Plugin Name                   leaks                                     
Host Name                     Bellatrix                                 
Platform                      Linux Bellatrix 2.6.32.3-17.fc12.x86_64 #1 SMP Tue
                              Jan 12 04:18:27 UTC 2010 x86_64 x86_64            
Alert Count                   1                                                 
First Seen                    Wed Jan  6 09:52:11 2010                          
Last Seen                     Wed Jan  6 09:52:11 2010                          
Local ID                      f8782cc0-57ce-4d43-a98f-a81d20dcc93e              
Line Numbers                  32, 33                                            

Raw Audit Messages            

type=AVC msg=audit(1262767931.517:27): avc:  denied  { write } for  pid=1811 comm="umount.crypt" path=2F7661722F72756E2F636F6E736F6C652F746F6F746561202864656C6574656429 dev=sda3 ino=21169 scontext=system_u:system_r:mount_t:s0-s0:c0.c1023 tcontext=system_u:object_r:pam_var_console_t:s0 tclass=file                                                                              

type=SYSCALL msg=audit(1262767931.517:27): arch=c000003e syscall=59 success=yes exit=0 a0=7fff85949c37 a1=105b5d0 a2=105a0c0 a3=3bcc880550 items=0 ppid=1673 pid=1811 auid=500 uid=0 gid=100 euid=0 suid=0 fsuid=0 egid=100 sgid=100 fsgid=100 tty=(none) ses=2 comm="umount.crypt" exe="/sbin/mount.crypt" subj=system_u:system_r:mount_t:s0-s0:c0.c1023 key=(null)
Comment 19 Daniel Walsh 2010-01-13 16:56:26 EST
This avc looks like a leaked file descriptor.

Could you put the machine in permissive mode and log in, to see if the file gets created?

Are you using an encrypted homedir?
Comment 20 Tomáš Trnka 2010-01-14 02:00:29 EST
Oh, booting with enforcing=0 actually caused the file to be created correctly...My bad, sorry for not testing this earlier...
However, it's rather strange no AVCs were reported to the audit log in enforcing mode...With permissive, I got these two polkit AVCs (however, sealert says polkit has a permissive type, so nothing was actually denied - I'm confused...)

Yes, I'm using an encrypted homedir auto-mounted on login via pam_mount

Summary:

SELinux is preventing /usr/libexec/polkit-1/polkitd "read" access on
/root/.config/user-dirs.dirs.

Detailed Description:

[polkitd has a permissive type (policykit_t). This access was not denied.]

(snip)

Additional Information:

Source Context                system_u:system_r:policykit_t:s0-s0:c0.c1023
Target Context                system_u:object_r:admin_home_t:s0
Target Objects                /root/.config/user-dirs.dirs [ file ]
Source                        polkitd
Source Path                   /usr/libexec/polkit-1/polkitd
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           polkit-0.95-0.git20090913.3.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-66.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     Bellatrix
Platform                      Linux Bellatrix 2.6.32.3-17.fc12.x86_64 #1 SMP Tue
                              Jan 12 04:18:27 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Thu Jan 14 07:44:42 2010
Last Seen                     Thu Jan 14 07:44:42 2010
Local ID                      1267b7bb-256c-489a-9657-9b26dc00b89c
Line Numbers                  90, 91, 92

Raw Audit Messages            

type=AVC msg=audit(1263451482.480:21): avc:  denied  { read } for  pid=2065 comm="polkitd" name="user-dirs.dirs" dev=md1p1 ino=6274 scontext=system_u:system_r:policykit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file

type=AVC msg=audit(1263451482.480:21): avc:  denied  { open } for  pid=2065 comm="polkitd" name="user-dirs.dirs" dev=md1p1 ino=6274 scontext=system_u:system_r:policykit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file

type=SYSCALL msg=audit(1263451482.480:21): arch=c000003e syscall=2 success=yes exit=7 a0=1a6c610 a1=0 a2=0 a3=1d items=0 ppid=2064 pid=2065 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="polkitd" exe="/usr/libexec/polkit-1/polkitd" subj=system_u:system_r:policykit_t:s0-s0:c0.c1023 key=(null)



--------------------------------------------------------------------------------


Summary:

SELinux is preventing /usr/libexec/polkit-1/polkitd "getattr" access on
/root/.config/user-dirs.dirs.

Detailed Description:

[polkitd has a permissive type (policykit_t). This access was not denied.]

(snip)

Additional Information:

Source Context                system_u:system_r:policykit_t:s0-s0:c0.c1023
Target Context                system_u:object_r:admin_home_t:s0
Target Objects                /root/.config/user-dirs.dirs [ file ]
Source                        polkitd
Source Path                   /usr/libexec/polkit-1/polkitd
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           polkit-0.95-0.git20090913.3.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-66.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     Bellatrix
Platform                      Linux Bellatrix 2.6.32.3-17.fc12.x86_64 #1 SMP Tue
                              Jan 12 04:18:27 UTC 2010 x86_64 x86_64
Alert Count                   1
First Seen                    Thu Jan 14 07:44:42 2010
Last Seen                     Thu Jan 14 07:44:42 2010
Local ID                      b698e849-e5b0-4078-b509-a2924438cd89
Line Numbers                  93, 94

Raw Audit Messages            

type=AVC msg=audit(1263451482.508:22): avc:  denied  { getattr } for  pid=2065 comm="polkitd" path="/root/.config/user-dirs.dirs" dev=md1p1 ino=6274 scontext=system_u:system_r:policykit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file

type=SYSCALL msg=audit(1263451482.508:22): arch=c000003e syscall=5 success=yes exit=0 a0=7 a1=7fff48735cb0 a2=7fff48735cb0 a3=1d items=0 ppid=2064 pid=2065 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="polkitd" exe="/usr/libexec/polkit-1/polkitd" subj=system_u:system_r:policykit_t:s0-s0:c0.c1023 key=(null)
Comment 21 Tomáš Trnka 2010-01-14 08:04:59 EST
Mystery solved!

I've found that logging in via TTY (/bin/login) creates the /var/run/console/tootea file correctly, only KDM fails. Enabling pam_console debug led to a discovery that the problem is pam_console not able to access /tmp/.X11-unix/X0 to check the console ownership. Why did this work only in permissive mode, while not throwing an AVC when enforcing? The answer is: The AVC is dontaudited in the policy. Disabling dontaudits I've found two relevant AVCs:

type=AVC msg=audit(1263471660.448:161): avc:  denied  { search } for  pid=5370 comm="kdm" name=".X11-unix" dev=tmpfs ino=13232 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir

and

type=AVC msg=audit(1263470933.826:126): avc:  denied  { getattr } for  pid=4771 comm="kdm" path="/tmp/.X11-unix/X0" dev=tmpfs ino=28410 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=sock_file

The first one is dontaudited in policy and since it fails in enforcing mode, the second one doesn't happen. Allowing both of them using a local policy module fixed the bug.
However, apparently the true problem is the bad labeling of /tmp/.X11-unix and /tmp/.X11-unix/X0 (both labelled initrc_tmp_t). Running restorecon fixes only the directory (to xserver_tmp_t). Manually chconing /tmp/.X11-unix/X0 to xserver_tmp_t (and removing the local module) fixes the bug (well, until the machine is rebooted, since my /tmp is on tmpfs).
Comment 22 Daniel Walsh 2010-01-14 09:20:22 EST
I have seen this bug before where .ICE-unix is labeled initrc_tmp_t.  Something is starting during the boot that is running as initrc_t which is creating these files with the wrong label.  We need to figure out what is doing this.
Comment 23 Tomáš Trnka 2010-01-14 10:37:22 EST
Correct...The culprit is /etc/init.d/freenx-server (freenx-server-0.7.3-17.fc12.x86_64) that does mkdir /tmp/.X11-unix when starting. Adding chcon -t xserver_tmp_t /tmp/.X11-unix there solves the problem. Shall I file a separate bug against freenx-server or will this be handled somehow else (reassigned?)?

(Wow...This bug has a rather interesting history: SELinux -> D-Bus -> PAM -> SELinux -> FreeNX :-))
Comment 24 Daniel Walsh 2010-01-14 11:30:53 EST
Nope this is freenx-servers bug.
Comment 25 Daniel Walsh 2010-01-14 11:32:17 EST
Created attachment 383717 [details]
Patch to fix context on /tmp/.X11-unix

Please add this patch to F11, F12 and RHEL6.
Comment 26 Kevin Kofler 2010-02-06 16:11:52 EST
*** Bug 562447 has been marked as a duplicate of this bug. ***
Comment 27 Kevin Kofler 2010-02-06 16:13:36 EST
*** Bug 562452 has been marked as a duplicate of this bug. ***
Comment 28 Dan Williams 2010-02-08 19:33:03 EST
*** Bug 549429 has been marked as a duplicate of this bug. ***
Comment 29 Kevin Kofler 2010-02-08 20:20:09 EST
This has much worse effects on F12 than on F11 (because HAL is now using D-Bus's at_console feature instead of using ConsoleKit and PolicyKit because that feature required PolicyKit 0.9) and is hitting quite some F12 KDE users (because KDE relies on HAL in many places).

Basically:
* the bad SELinux context on /tmp/.X11-unix breaks pam_console,
* that breaks D-Bus's at_console detection (why isn't that using ConsoleKit these days?),
* that in turn breaks HAL,
* and that in turn breaks KDE.

The patch to fix this issue is 1 line. Why is it still not applied after a month?
Comment 30 Fedora Update System 2010-02-14 11:25:48 EST
fail2ban-0.8.4-24.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-24.fc11
Comment 31 Fedora Update System 2010-02-14 11:25:59 EST
fail2ban-0.8.4-24.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-24.fc12
Comment 32 Fedora Update System 2010-02-14 11:36:22 EST
freenx-server-0.7.3-18.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/freenx-server-0.7.3-18.fc12
Comment 33 Fedora Update System 2010-02-14 11:36:27 EST
freenx-server-0.7.3-18.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/freenx-server-0.7.3-18.fc11
Comment 34 Fedora Update System 2010-02-16 08:06:18 EST
freenx-server-0.7.3-18.fc11 has been pushed to the Fedora 11 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 freenx-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-1848
Comment 35 Fedora Update System 2010-02-16 08:22:37 EST
freenx-server-0.7.3-18.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 freenx-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1932
Comment 36 Kevin Kofler 2010-03-01 06:52:30 EST
*** Bug 550013 has been marked as a duplicate of this bug. ***
Comment 37 Kevin Kofler 2010-03-02 16:38:41 EST
*** Bug 568656 has been marked as a duplicate of this bug. ***
Comment 38 Charlweed Hymerfan 2010-03-05 15:07:17 EST
I use KDM (on F11), and I have this same  problem.
Touching /var/run/console/foo works around it, as noted above.
But does the patch to freenx-server or fail2ban help when the bug is incounterd in KDM? 

Is there a fix for F11 KDM?
Comment 39 Charlweed Hymerfan 2010-03-05 15:26:41 EST
What I meant to say is that I don't have freenx-server or fail2ban installed, and I still have the same problem.
Nor do I have /tmp/.X11-unix
So is there some chcon or restorecon that I can use to fix this?

This is my /tmp with KDM running:

drwxrwxrwt. root           root           system_u:object_r:tmp_t:s0       .
drwxr-xr-x. root           root           system_u:object_r:root_t:s0      ..
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 .esd-2106
drwx------. gdm            gdm            system_u:object_r:xdm_tmp_t:s0   .esd-42
drwx------. installerlocal installerlocal unconfined_u:object_r:user_tmp_t:s0 .esd-500
drwx------. vmadmin        vmadmin        unconfined_u:object_r:user_tmp_t:s0 .esd-502
-rw-r--r--. root           root           system_u:object_r:tmp_t:s0       firstbootX.log
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 gpg-O9KzR9
drwxrwxrwt. root           root           system_u:object_r:xdm_tmp_t:s0   .ICE-unix
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 kde-chymes
drwx------. installerlocal installerlocal unconfined_u:object_r:user_tmp_t:s0 kde-installerlocal
drwx------. root           root           system_u:object_r:user_tmp_t:s0  kde-root
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 keyring-9DDNBg
-rw-------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 krb5cc_2106_AdatTe
-rw-------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 krb5cc_2106_NyO89t
-rw-------. chymes         domain users   system_u:object_r:sshd_tmp_t:s0  krb5cc_2106_o49WBl
-rw-------. chymes         domain users   system_u:object_r:xdm_tmp_t:s0   krb5cc_2106_wjQP78
-rw-------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 krb5cc_2106_ZoJAgt
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 ksocket-chymes
drwx------. installerlocal installerlocal unconfined_u:object_r:user_tmp_t:s0 ksocket-installerlocal
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 orbit-chymes
drwx------. installerlocal installerlocal unconfined_u:object_r:user_tmp_t:s0 orbit-installerlocal
drwx------. root           root           unconfined_u:object_r:user_tmp_t:s0 orbit-root
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 pulse-26u8CnwdTIzw
drwx------. gdm            gdm            system_u:object_r:xdm_tmp_t:s0   pulse-ilj2mJgVJQdK
drwx------. installerlocal installerlocal unconfined_u:object_r:user_tmp_t:s0 pulse-OLMpyrKgJehR
drwx------. vmadmin        vmadmin        unconfined_u:object_r:user_tmp_t:s0 pulse-OTThTrYXtB8E
drwx------. chymes         domain users   unconfined_u:object_r:user_tmp_t:s0 ssh-lDOUD10402
drwx------. vmadmin        vmadmin        system_u:object_r:initrc_tmp_t:s0 .vbox-vmadmin-ipc
drwx------. installerlocal installerlocal unconfined_u:object_r:user_tmp_t:s0 virtual-installerlocal.AKrac7
drwx------. installerlocal installerlocal unconfined_u:object_r:user_tmp_t:s0 virtual-installerlocal.K5QT1A
-rw-r--r--. root           root           system_u:object_r:root_t:s0      yum.log
Comment 40 Daniel Walsh 2010-03-05 15:43:57 EST
Charlweed, please open a new bugzilla stating what your problem is.  THis one is too confusing at this point.
Comment 41 Daniel Walsh 2010-03-10 16:27:26 EST
*** Bug 549253 has been marked as a duplicate of this bug. ***
Comment 42 Fedora Update System 2010-03-11 02:19:02 EST
freenx-server-0.7.3-18.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 43 Fedora Update System 2010-03-11 02:25:48 EST
freenx-server-0.7.3-18.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 44 Matt Castelein 2010-03-12 17:30:43 EST
I'm not happy with this update.  After installing it, all sessions but the very first after a reboot time out with messages in the logs like this:

WARNING: Application 'gnome-panel.desktop' failed to register before timeout

I get the lovely spinning fedora arrow for a while then blackness for a very long time, then if I am lucky parts of the gnome interface will come up with a bunch of dialogs about timeouts.  Change it back!
Comment 45 Matt Castelein 2010-03-14 10:03:24 EDT
(In reply to comment #44)
> I'm not happy with this update.  After installing it, all sessions but the very
> first after a reboot time out with messages in the logs like this:
> 
> WARNING: Application 'gnome-panel.desktop' failed to register before timeout
> 
> I get the lovely spinning fedora arrow for a while then blackness for a very
> long time, then if I am lucky parts of the gnome interface will come up with a
> bunch of dialogs about timeouts. 

This appears related to problems I'm having with ext4..  Probably has nothing to do with freenx directly.  Sorry for confusion.