Bug 499183
| Summary: | freenx-server script creates /tmp/.X11-unix without a valid SELinux context | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeff Layton <jlayton> | ||||
| Component: | freenx-server | Assignee: | Axel Thimm <axel.thimm> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 11 | CC: | armandsl, axel.thimm, czml1, dev, dwalsh, dzrudy, eric.tanguy, gwync, jdennis, kevin, 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 07:19:12 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 549429 | ||||||
| Attachments: |
|
||||||
|
Description
Jeff Layton
2009-05-05 14:51:32 UTC
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 Do you have the client installed? setroubleshoot-2.1.8-1.fc11.x86_64 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 Works for me. Did you just update to this? Have you rebooted? I think you need to restart the messagebus 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? *** Bug 499218 has been marked as a duplicate of this bug. *** cat /usr/share/dbus-1/services/sealert.service [D-BUS Service] Name=org.fedoraproject.Setroubleshootd Exec=/usr/bin/sealert -s 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?) Ray or Colin can you comment, On the two F11 boxes I have this is working fine. 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. 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. 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 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 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. ls -lZ /var/run/console [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. 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) 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? 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)
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).
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. 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 :-)) Nope this is freenx-servers bug. Created attachment 383717 [details]
Patch to fix context on /tmp/.X11-unix
Please add this patch to F11, F12 and RHEL6.
*** Bug 562447 has been marked as a duplicate of this bug. *** *** Bug 562452 has been marked as a duplicate of this bug. *** *** Bug 549429 has been marked as a duplicate of this bug. *** 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? 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 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 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 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 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 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 *** Bug 550013 has been marked as a duplicate of this bug. *** *** Bug 568656 has been marked as a duplicate of this bug. *** 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? 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 Charlweed, please open a new bugzilla stating what your problem is. THis one is too confusing at this point. *** Bug 549253 has been marked as a duplicate of this bug. *** 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. 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. 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! (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. |