1. 01 Oct, 2019 1 commit
  2. 25 Sep, 2017 1 commit
  3. 26 Oct, 2016 1 commit
  4. 03 Dec, 2015 1 commit
  5. 19 Oct, 2015 3 commits
  6. 04 Jan, 2015 1 commit
    • Peter Hutterer's avatar
      xfree86: rename Xorg.bin to Xorg · de89c6b8
      Peter Hutterer authored
      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's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Acked-by: default avatarHans de Goede <hdegoede@redhat.com>
  7. 18 Apr, 2014 3 commits
  8. 12 Mar, 2014 1 commit
    • Hans de Goede's avatar
      Xorg: Add a suid root wrapper · e7b84ca4
      Hans de Goede authored
      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: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>