Bug 712432 - /usr/bin/Xorg binary is not readable by non-root
Summary: /usr/bin/Xorg binary is not readable by non-root
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 17
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Whiteboard: [cat:others]
Keywords: Triaged
Depends On:
Blocks: F17Blocker, F17FinalBlocker
TreeView+ depends on / blocked
Reported: 2011-06-10 15:23 UTC by Daniel Berrange
Modified: 2012-03-21 18:40 UTC (History)
2 users (show)

Clone Of:
: 853236 (view as bug list)
Last Closed: 2012-03-21 18:40:51 UTC

Attachments (Terms of Use)

Description Daniel Berrange 2011-06-10 15:23:17 UTC
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:


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):

How reproducible:

Steps to Reproduce:
1. As non-root user, attempt to read /usr/bin/Xorg binary
Actual results:
Permission denied

Expected results:
Binary is readable

Additional info:

Comment 1 Daniel Berrange 2012-01-04 13:29:58 UTC
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.

/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.

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.

Comment 2 Daniel Berrange 2012-03-14 11:24:34 UTC
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.

Comment 3 Fedora Update System 2012-03-14 15:07:35 UTC
xorg-x11-server-1.12.0-2.fc17 has been submitted as an update for Fedora 17.

Comment 4 Adam Williamson 2012-03-14 22:12:28 UTC
'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

Comment 5 Daniel Berrange 2012-03-15 10:07:04 UTC
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

Comment 6 Adam Williamson 2012-03-15 17:29:11 UTC
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

Comment 7 Fedora Update System 2012-03-16 02:43:28 UTC
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:
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2012-03-21 18:40:51 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.