Description of problem: I am experimenting with running KVM guests using a filesystem which is passed through from the host OS. In the guest I need to run an X server, but the /usr/bin/Xorg binary is not readable by non-root users, so the KVM process can't access it. # ls -l /usr/bin/Xorg -rws--x--x. 1 root root 1979760 Mar 18 00:23 /usr/bin/Xorg In this thread: http://www.redhat.com/archives/fedora-devel-list/2009-October/msg01007.html it is initially said that removing group/other read permission is required to avoid non-root users getting a core dump containing privileged data. The later message in that thread, however, indicates that the kernel blocks core dumps on setuid binaries, regardless of 'read' permission bit. So is there any other obstacle to making the Xorg binary 04777 instead of 04711 ? If not I could really do with Xorg being made world readable. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.9.5-1.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1. As non-root user, attempt to read /usr/bin/Xorg binary 2. 3. Actual results: Permission denied Expected results: Binary is readable Additional info:
Looking at the kernel source / proc manpages, confirms setuid binaries cannot be dumped by default, or can be dumped in a "safe" mode where the dump is only readable by root. [quote] /proc/sys/fs/suid_dumpable (since Linux 2.6.13) The value in this file determines whether core dump files are produced for set-user-ID or otherwise protected/tainted binaries. Three different integer values can be specified: 0 (default) This provides the traditional (pre-Linux 2.6.13) behavior. A core dump will not be produced for a process which has changed credentials (by calling seteuid(2), setgid(2), or similar, or by executing a set-user-ID or set-group-ID program) or whose binary does not have read permission enabled. 1 ("debug") All processes dump core when possible. The core dump is owned by the file system user ID of the dumping process and no security is applied. This is intended for system debugging situations only. Ptrace is unchecked. 2 ("suidsafe") Any binary which normally would not be dumped (see "0" above) is dumped readable by root only. This allows the user to remove the core dump file but not to read it. For security reasons core dumps in this mode will not overwrite one another or other files. This mode is appropriate when administrators are attempting to debug problems in a normal environment. [/quote] Given this, the coredump issue does not appear to be a compelling reason to restrict /usr/bin/Xorg to mode 04711. Is there any other reason to keep it 04711 ? If not, I would very much like it to be changed to 04777, so I can read & execute Xorg inside a KVM guest, while using host filesystem passthrough.
I would really like this bug fixed for Fedora 17, to satisfy part of the libvirt sandbox functionality. We need to be able to run Xorg from a non-root user account to setup a display in the guest, which requires non-root having read/execute permission on the binary.
xorg-x11-server-1.12.0-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xorg-x11-server-1.12.0-2.fc17
'I would really like this to be fixed' is not sufficient justification for making a bug a blocker. The blocker trackers are not there to keep track of 'bugs people really want fixed': they are there to track bugs that would genuinely cause us to delay the release if they are not fixed. So, with that in mind, we are unlikely to accept this as a blocker without a justification beyond what's given so far. If you still want the bug to block the release, please explain how it violates the release criteria - https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria . Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I marked it as a blocker, because it impacts on the functionality of an approved Fedora feature https://fedoraproject.org/wiki/Features/VirtSandbox. In any case, there's no problem here because this bug is already in MODIFIED
The feature process and the release validation process are explicitly separate, by policy. An incomplete feature does not, in and of itself, constitute a release blocking issue. Each release criteria page contains the text "A Fedora feature being incomplete, in and of itself, does not constitute a blocker bug. The feature process is separate from this process. Features are required to meet certain standards at certain points of the release cycle, but this is part of the feature process and managed, tracked and enforced separately from this process. However, if a proposed feature being incomplete causes any of the above criteria to be met, then the bug is a release blocker." -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Package xorg-x11-server-1.12.0-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.12.0-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-3858/xorg-x11-server-1.12.0-2.fc17 then log in and leave karma (feedback).
xorg-x11-server-1.12.0-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.