Why is our xorg-server setuid, again?

Message

Post by **pjp** » Sat Nov 03, 2018 11:23 pm

Split off What really is changing in these xorg releases?

EasterParade · Post by **EasterParade** » Sun Nov 04, 2018 9:35 am

I´ m not certain if this is related. Apologies if this is the wrong thread.
The recent upgrade to x11-base/xorg-server-1.20.3 caused X not to start here
on a openrc system with the following error message:
parse_vt_settings Cannot open /dev/tty0 Permission denied.
Had to mask xorg-server-1.20.3 and downgrade to xorg-server-1.19.5-r2 .
Now X starts again.

May be it is about time I switch to systemd. There are a few other issues
where openrc collides with stuff i.e. plasma.

Post by **asturm** » Sun Nov 04, 2018 10:40 am

Yes it is related, because the default is now non-suid.

transsib wrote:May be it is about time I switch to systemd.

Not necessary, you need to set xorg-server[suid].

transsib wrote:There are a few other issues where openrc collides with stuff i.e. plasma.

Certainly not, why would Plasma collide with an init system.

Naib · Post by **Naib** » Sun Nov 04, 2018 10:42 am

transsib wrote:I´ m not certain if this is related. Apologies if this is the wrong thread.
The recent upgrade to x11-base/xorg-server-1.20.3 caused X not to start here
on a openrc system with the following error message:
parse_vt_settings Cannot open /dev/tty0 Permission denied.
Had to mask xorg-server-1.20.3 and downgrade to xorg-server-1.19.5-r2 .
Now X starts again.

May be it is about time I switch to systemd. There are a few other issues
where openrc collides with stuff i.e. plasma.

the quick solution is re-emerge xorg-server with the suid flag set

emerge xorg-server -va

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] x11-base/xorg-server-1.20.3:0/1.20.3::gentoo USE="glamor ipv6 udev xorg -debug -dmx -doc -kdrive -libressl -minimal (-selinux) -static-libs -suid -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb" 0 KiB

This will revert behaviour and does expose the issue this thread is discussing. If you are the only one using your machine you do not need to really worry (as much ... prying eyes).
I don't have suid set, I use openRC but I don't have the concern you are talking about. I however do use lightDM as the desktop manage and do not use startX to immediately login. all the reports in gentoo of people having this problem appear to be startx related:
You could also setup xorg correctly:

viewtopic-t-1053260-highlight-startx.html -> https://wiki.gentoo.org/wiki/Non_root_Xorg
viewtopic-t-1088842-highlight-startx.html

or the poor-mans method
viewtopic-t-1088836-highlight-startx.html

I am not sure what going to systemd would fix in this instance while bring lots of other concerns. One option might be to have consolekit and elogin installed and started by openRC to provide the (possible) additional features to a multi-head setup.

Post by **asturm** » Sun Nov 04, 2018 10:45 am

Naib wrote:One option might be to have consolekit and elogin installed

consolekit and elogind are exclusive-or.

Naib · Post by **Naib** » Sun Nov 04, 2018 10:57 am

asturm wrote:
Naib wrote:One option might be to have consolekit and elogin installed
consolekit and elogind are exclusive-or.

ahh, does elogin then provide consolekit-like capability (setting permissions). I don't know both, I just know these are spinoff's from systemd to support non-systemd systems when such functionality was forced onto the user

Post by **asturm** » Sun Nov 04, 2018 11:02 am

consolekit predates systemd and only gained logind-style capabilities recently (I have no idea to what extent this is functional, at least it is not drop-in support meaning packages need to get patched), elogind is basically standalone logind ripped out of systemd, for use with traditional init systems. Packages need to be built with either consolekit or elogind or systemd support globally. If you mix, you will run into undefined behavior (which makes the recent addition of elogind/systemd as a dependency of skypeforlinux especially bad).

So yes, in theory if suid-wrapper just needs logind, elogind should be an easy alternative to systemd.

Anon-E-moose · Post by **Anon-E-moose** » Sun Nov 04, 2018 11:21 am

Naib wrote:
transsib wrote:I´ m not certain if this is related. Apologies if this is the wrong thread.
The recent upgrade to x11-base/xorg-server-1.20.3 caused X not to start here
on a openrc system with the following error message:
parse_vt_settings Cannot open /dev/tty0 Permission denied.
Had to mask xorg-server-1.20.3 and downgrade to xorg-server-1.19.5-r2 .
Now X starts again.

May be it is about time I switch to systemd. There are a few other issues
where openrc collides with stuff i.e. plasma.
the quick solution is re-emerge xorg-server with the suid flag set

The quickest solution is to "chmod 4711 /usr/bin/Xorg" as root

Naib · Post by **Naib** » Sun Nov 04, 2018 11:23 am

Anon-E-moose wrote:
Naib wrote:
transsib wrote:I´ m not certain if this is related. Apologies if this is the wrong thread.
The recent upgrade to x11-base/xorg-server-1.20.3 caused X not to start here
on a openrc system with the following error message:
parse_vt_settings Cannot open /dev/tty0 Permission denied.
Had to mask xorg-server-1.20.3 and downgrade to xorg-server-1.19.5-r2 .
Now X starts again.

May be it is about time I switch to systemd. There are a few other issues
where openrc collides with stuff i.e. plasma.
the quick solution is re-emerge xorg-server with the suid flag set
The quickest solution is to "chmod 4711 /usr/bin/Xorg" as root

login as root

dmpogo · Post by **dmpogo** » Sun Nov 04, 2018 3:12 pm

asturm wrote:consolekit predates systemd and only gained logind-style capabilities recently (I have no idea to what extent this is functional, at least it is not drop-in support meaning packages need to get patched), elogind is basically standalone logind ripped out of systemd, for use with traditional init systems. Packages need to be built with either consolekit or elogind or systemd support globally. If you mix, you will run into undefined behavior (which makes the recent addition of elogind/systemd as a dependency of skypeforlinux especially bad).

So yes, in theory if suid-wrapper just needs logind, elogind should be an easy alternative to systemd.

I still failed to make elogind play nicely with sddm, strangely one two out of three my machines, the ones with proprietary nvidia-drivers (why would that matter). SDDM fails to start if elogind is already running, I need to make sure that it is not to succesfully start SDDM

EasterParade · Post by **EasterParade** » Sat Nov 10, 2018 10:44 am

So.... I tried to fix this following the guide Naib pointed me at.
But X would not like to start; error same as before.
I put the new xorg-server back into package.mask and wanted to downgrade when I saw
that even x11-base/xorg-server-1.19.5-r2 had the suid USE flag set as well.

With all due respect but this behaviour is dubious.

I set xorg-server-1.19.5-r2 into package.use as -suid and reemrged stuff yet
X still wouldn´t start because.... reasons.

Is it possible that I have to remove changes for udev and .xinitrc too to get X back up again?

Post by Hu » Sat Nov 10, 2018 4:26 pm

If you use Xorg with USE=+suid, then everything should work, albeit with the security risks associated with running a large and complicated program as root. If you use Xorg with USE=-suid, or install one of the versions that does not have IUSE=suid, then you must complete one of the guides for granting unprivileged Xorg access to the required devices. If you need help, I suggest opening a separate thread (and mentioning it here), showing the specific errors you get, showing the output of emerge -pv x11-base/xorg-server, and describing exactly which steps from which guide(s) you have performed. I also suggest that you upgrade back to the 1.20 series until we determine that it has a relevant regression.

Post by **pjp** » Sat Nov 10, 2018 5:24 pm

Do we know what "turned on" +suid? I haven't touched the suid setting one way or another, it appears to be disabled.

Ah, never mind. It was one of those changes which are allowed without an ebuild revision.

*sigh*

Is there a way to mask that kind of thing?

Code: Select all

$ diff /var/db/pkg/x11-base/xorg-server-1.20.3/xorg-server-1.20.3.ebuild /usr/portage/x11-base/xorg-server/xorg-server-1.20.3.ebuild
6d5
< XORG_EAUTORECONF=yes
14c13
<       KEYWORDS="alpha amd64 ~arm ~arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux"
---
>       KEYWORDS="alpha amd64 arm ~arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux"
17c16
< IUSE_SERVERS="dmx kdrive wayland xephyr xnest xorg xvfb"
---
> IUSE_SERVERS="dmx kdrive suid wayland xephyr xnest xorg xvfb"
167c166
<               $(use_enable !systemd install-setuid)
---
>               $(use_enable suid install-setuid)
200a200,201
> 
>       find "${ED}"/var -type d -empty -delete || die

Post by **asturm** » Sat Nov 10, 2018 5:28 pm

It's a USE flag, just disable it? PS: It was enabled all the way up to the recent 1.20 release, then re-added because of too many bug reports.

Post by **pjp** » Sat Nov 10, 2018 6:11 pm

I was thinking "changes to ebuilds which don't get a revision bump."

Masking the USE flag doesn't seem to help. If I make no changes:

Code: Select all

$ emerge -vp xorg-server

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] x11-base/xorg-server-1.20.3:0/1.20.3::gentoo  USE="glamor libressl udev xorg -debug -dmx -doc -ipv6 -kdrive -minimal (-selinux) -static-libs -suid% -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb"

If I add "=x11-base/xorg-server-1.20.3 suid" to package.use:

Code: Select all

$ emerge -vp xorg-server

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] x11-base/xorg-server-1.20.3:0/1.20.3::gentoo  USE="glamor libressl suid%* udev xorg -debug -dmx -doc -ipv6 -kdrive -minimal (-selinux) -static-libs -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb"

Either way, it wants to rebuild because of hte USE flag change. It works as installed, recompiling it will provide zero benefit. This really ought to have been bumped.

Post by **asturm** » Sat Nov 10, 2018 6:15 pm

Pardon my ignorance, but `emerge -vp xorg-server` will always make you rebuild. But if it is bumped... you'll have to "re-" build as well?

EasterParade · Post by **EasterParade** » Sat Nov 10, 2018 7:32 pm

Gonna start what Dr. Hu recommended tomorrow. This is really annoying.
I mean really really annoying.

Ant P. · Post by **Ant P.** » Sat Nov 10, 2018 10:38 pm

Maybe instead of a USE flag it should be a pkg_config. Ask the user if they want a plain unprivileged binary for service managers, setgid tty for startx users, or a setuid root for... whatever. People who refuse to give their account input device access at all?

Post by **pjp** » Sat Nov 10, 2018 11:21 pm

asturm wrote:Pardon my ignorance, but `emerge -vp xorg-server` will always make you rebuild.

I was trying to show the relevant USE flag. In the first output, it is "-suid%" in the second output, it is "suid%*". % "newly added or removed," * "transition to or from enabled state."

asturm wrote:It's a USE flag, just disable it?

How is a USE flag disabled without triggering a state change?

asturm wrote:But if it is bumped... you'll have to "re-" build as well?

And I can mask that version.

Post by **asturm** » Sat Nov 10, 2018 11:33 pm

pjp wrote:How is a USE flag disabled without triggering a state change?

State change only matters if you routinely build with -N, which is a bit contradictory if you are hellbent on avoiding unnecessary builds.

Post by **pjp** » Sun Nov 11, 2018 3:11 am

I'll have to assume it was -N. With or without -N now, it doesn't show up. I had updated zlib, libxml2, and harfbuzz for unrelated USE flags changes (icu & minizip), so maybe they were also somehow triggering a rebuld of xorg-server. I've been trying to break an old habit of using -N. Thanks for the help.

EasterParade · Post by **EasterParade** » Sun Nov 11, 2018 10:13 am

I used the wiki. Got it working now after rolled everything back and repeated the changes.
I also used startx -- vt1 and got X back up.

Gonna keep OpenRC for now. Thanks.

Marcih · Post by **Marcih** » Sun Nov 11, 2018 7:38 pm

Ant P. wrote:Maybe instead of a USE flag it should be a pkg_config. Ask the user if they want a plain unprivileged binary for service managers, setgid tty for startx users, or a setuid root for... whatever. People who refuse to give their account input device access at all?

I like that idea.

Related to the comment on people refusing to "give their account input device access at all": What exactly does running X with setgid to the input group do? The way I understand it is that the binary runs with the same privilidges as a hypothetical user in the group that owns it (input in this case). If that is the case then the only program with access to input devices is the X server (because you as the user are not in the input group hence access to the input devices is not granted).

Where is the issue? I suppose the same theoretical "what could possibly go wrong" applies with the suid wrapper and look where that took us; still, even if such exploit was found, it would only grant the attacker access to input (and the possibility for keyloggers, bleh) and not full-blown root access.

Post by **pjp** » Sun Nov 11, 2018 9:33 pm

Marcih wrote:
Ant P. wrote:Maybe instead of a USE flag it should be a pkg_config. Ask the user if they want a plain unprivileged binary for service managers, setgid tty for startx users, or a setuid root for... whatever. People who refuse to give their account input device access at all?
I like that idea.

Asking the user? As in with a prompt that waits for input?

Anon-E-moose · Post by **Anon-E-moose** » Sun Nov 11, 2018 9:53 pm

They should have left the whole suid thing alone, those who didn't want to run it suid, already knew how to do it or could find out easily.

If they had to do anything, then a news item triggered off on having xorg-server emerged would have sufficed, or put a warning at the beginning or end of the ebuild.

They created more trouble than it's worth, with the hokey-pokey, put it in, take it out, shake it all about, and then to top it off not changing the ebuild with an -rN.