supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Guillermo <gdiazhartusch@gmail.com>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: s6 xinit replacement?
Date: Mon, 23 May 2022 20:40:44 -0300	[thread overview]
Message-ID: <CADQ2Nw-_QDj_J9sFzD4iwQdKXRbB-n+9vNJDpYBagWcCUtFhLA@mail.gmail.com> (raw)
In-Reply-To: <cc0d7f3f-348e-4478-7380-d832b1402abf@disroot.org>

Hello, yianiris / fungal-net

El lun, 23 may 2022 a las 7:07, yianiris escribió:
>
> Unbelievable, on this particular list, someone suggesting that dbus or
> systemd (elogind is the most invasive of all parts of systemd) is needed
> to run X [...]

Oh, I'm not suggesting it, I am stating it as a fact :)

OK, now more seriously. This has come up some time ago in the Gentoo
Forums when Gentoo's 'suid' USE flag changed to unset by default; the
correct (although somewhat simplified for brevity) way to state that
assertion is: the only *officialy supported* way to *not* run Xorg as
root is by having it get open file descriptors from a "logind
provider" (a process that implements the D-Bus org.freedesktop.login1
interface) using file descriptor passing, for /dev special files that
would otherwise require a privileged open() call.

Why? Because that is how Xorg is currently programmed. Technical
details in this old version of a Gentoo Wiki article, if you are
interested:

* https://wiki.gentoo.org/index.php?title=Non_root_Xorg&oldid=884856#Supported_setups

Personally, I don't mind D-Bus and elogind that much, because they
combine well with an s6-based init system:

  PID COMMAND
    1 s6-svscan -X3 -- /run/service
  106 s6-supervise dbus-daemon
  438  \_ dbus-daemon --system --nofork --nopidfile
  480 elogind-daemon

$ s6-rc-db type dbus-daemon
longrun

That said, I know that there are people who do not like D-Bus and / or
elogind, and don't want them installed. That's OK, it's their choice.

> no logind no dbus 0 logind/dbus warning/error messages.

I hope you read the "I suppose that Xorg is not a suid binary" and
"unless you do something else" parts of my previous e-mail. Setups
without a suid Xorg binary, without D-Bus, and without a logind
provider, need to work around the privileged open() situation:

* AFAICT, Void and Obarun build Xorg with '-Dsuid_wrapper=true', so
they install the Xorg suid wrapper, and configure it to never drop
privileges by default.
<https://github.com/void-linux/void-packages/blob/master/srcpkgs/xorg-server/template>
<https://github.com/void-linux/void-packages/blob/master/srcpkgs/xorg-server/files/Xwrapper.config>
<https://framagit.org/pkg/obextra/xorg-server/-/blob/master/trunk/PKGBUILD>
<https://framagit.org/pkg/obextra/xorg-server/-/blob/master/trunk/Xwrapper.config>

* Samuel adds his user to a group that allows processes to perform the
required privileged open() calls. (What Rio's setup does with respect
to /dev/dri/card* files has not been specified).

All of these require some form of elevated privileges, including
effectively running Xorg as root even if its binary might not be suid
(its helper, Xorg.wrap, is). If your setup works in a way that does
not involve elevated privileges, to be honest, I'd rather read about
*that* instead of yet another systemd / RedHat / IBM rant.

> Again, sorry Guillermo, this is not personal [...]

No worries, no offense taken.

G.

  reply	other threads:[~2022-05-23 23:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11  3:36 dallinjdahl
2022-05-14  3:47 ` Guillermo
2022-05-14 23:45   ` dallinjdahl
2022-05-15  1:52     ` Laurent Bercot
2022-05-15 15:02       ` Guillermo
2022-05-17  4:10         ` Rio Liu
2022-05-15  2:44   ` Samuel Holland
2022-05-22 15:07     ` Guillermo
2022-05-22 16:33       ` Samuel Holland
2022-05-23 10:05       ` yianiris
2022-05-23 23:40         ` Guillermo [this message]
2022-05-27  2:04         ` Steve Litt
2022-05-28  4:07     ` Dallin Dahl
2022-05-28 17:15     ` Dallin Dahl
2022-05-28 19:43       ` Samuel Holland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADQ2Nw-_QDj_J9sFzD4iwQdKXRbB-n+9vNJDpYBagWcCUtFhLA@mail.gmail.com \
    --to=gdiazhartusch@gmail.com \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).