summaryrefslogtreecommitdiff
path: root/hw/xfree86/Xorg.sh.in
AgeCommit message (Collapse)AuthorFilesLines
2015-01-05xfree86: rename Xorg.bin to XorgPeter Hutterer1-2/+2
If the suid wrapper is enabled, /usr/bin/Xorg is just a shell script that execs either /usr/libexec/Xorg.bin directly or the Xorg.wrap binary which then execve's /usr/libexec/Xorg.bin. Either way, we end up with Xorg.bin, which is problematic for two reasons: * ps shows the command as Xorg.bin * _COMM and _EXE in systemd's journal will both show Xorg.bin as well There's not much we can do about the path, but having the actual command stay as Xorg means better compatibility to existing scripts. And, the reason for this path: the command journalctl _COMM=Xorg works universally, regardless of whether the wrapper is used or not. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2014-03-12Xorg: Add a suid root wrapperHans de Goede1-0/+11
With the recent systemd-logind changes it is possible to install the Xorg binary without suid root rights and still have everything working as it should *if* the user only has cards which are supported by kms. This commit adds a little suid root wrapper, which is a bit weird, first we strip the suid-root bit of the Xorg binary, and then we add a wrapper ? The function of this wrapper is to see if a system still needs root-rights, if it does not (it supports kms and the kms drivers are properly loaded), then it will immediately drop all elevated rights before executing the real Xorg binary. If it finds (some) cards which don't support kms, or no cards at all, then it will execute the Xorg server with elevated rights so that ie the nvidia binary driver and the vesa driver can keep working normally. To make it possible for security concious users who don't need the root rights to completely remove the wrapper, Xorg is started in a 3 step process when the wrapper is enabled during build time: 1) A simple shell script which checks if the wrapper is there, if it is it executes the wrapper, if not it directly executes the real Xorg binary 2) The wrapper gets executed, does its checks, normally drops all elevated rights and then executes the real Xorg binary 3) The real Xorg binary does its thing This allows distributions to put the wrapper binary in a separate package, and will allow users to remove this package. IE the plan with Fedora is to make "legacy" drivers depend on the wrapper pkg, and since our default install contains some legacy drivers it will be part of the default install, but users can later yum remove it (which will also automatically remove the legacy driver packages as those won't work without it anyways). The wrapper is loosely modelled after the existing Debian Xwrapper, it uses the same config-file + config-file format, and also allows restricting Xserver execution (through the wrapper) to console users only. There also is a new needs_root_rights config file directive, which can be used to override the auto-detection the wrapper does. Hopefully this will allow Debian to replace their own wrapper with this upstream one. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>