Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 669648 - x11-base/xorg-server: add USE=suid so that /usr/bin/Xorg setuid can be disabled
Summary: x11-base/xorg-server: add USE=suid so that /usr/bin/Xorg setuid can be disabled
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords: PATCH
: 670200 670860 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-25 23:26 UTC by Hank Leininger
Modified: 2018-11-10 21:36 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Add a setuid knob to control +s on /usr/bin/Xorg, on by default for backwards compat (xorg-server-USE_setuid.patch,1.07 KB, patch)
2018-10-25 23:26 UTC, Hank Leininger
Details | Diff
Add a suid knob to control +s on /usr/bin/Xorg, on by default for backwards comp (xorg-server-USE_suid.patch,1.12 KB, patch)
2018-10-25 23:31 UTC, Hank Leininger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hank Leininger 2018-10-25 23:26:03 UTC
Created attachment 553058 [details, diff]
Add a setuid knob to control +s on /usr/bin/Xorg, on by default for backwards compat

Please consider adding a knob, so that Gentoo admins can choose to set USE=-setuid to avoid chmod +s on /usr/bin/Xorg.  Setuid is only required when not using a launcher/display manager like xdm, gdm, lightdm that already runs as root.  We currently force +s on unless systemd is in use.

I will attach a patch that adds IUSE="+setuid", so that the default behavior is unchanged, but admins can set -setuid to avoid security impacts from a setuid Xorg server.

I first raised this in bug 669588, a version bump due to a vulnerability in Xorg when it is setuid, and was asked to make it a separate bug instead.

Looking around in b.g.o it seems there used to be a suid flag, which was removed in some previous version; some relevant (but not duplicate) bugs: bug 419485, bug 425808, bug 450364.

It seems to me there have been some issues with Xorg running as non-root wrt some particular drivers, etc. - but none of that is a problem if launched by a display manager running as root.

There is also a suid-wrapper that some distros use - and which perhaps Gentoo used to use?  That's interesting but I think not relevant/required for the DM use case.
Comment 1 Hank Leininger 2018-10-25 23:31:27 UTC
Created attachment 553060 [details, diff]
Add a suid knob to control +s on /usr/bin/Xorg, on by default for backwards comp

Renamed USE flag to 'suid' to match what is used by other packages.
Comment 2 Hanno Böck gentoo-dev 2018-10-26 06:33:02 UTC
I wonder if we should go a step further and make this secure by default and default to off.

According to your comment in #669588 suid is only required for people manually starting the X server, and not for display managers. I'd say this means few users will need a suid X binary, so it should be okay to let those few enable it manually and have the safer option for the majority.
Comment 3 Alexander Tsoy 2018-10-26 08:25:40 UTC
(In reply to Hanno Boeck from comment #2)
> According to your comment in #669588 suid is only required for people
> manually starting the X server, and not for display managers.
The things are more complicated:
- with systemd you actually can manually start X server without suid bit;
- suid bit is absolutely required for non-KMS video drivers. I Just tested GDM with mga driver: X server fails to start without suid wraper.
Comment 4 Alexander Tsoy 2018-10-26 08:29:48 UTC
(In reply to Alexander Tsoy from comment #3)
> - with systemd you actually can manually start X server without suid bit;
And I wonder is it possible to add elogind support to X server for non-systemd users?
Comment 5 Hanno Böck gentoo-dev 2018-10-26 08:53:23 UTC
> - suid bit is absolutely required for non-KMS video drivers. I Just tested GDM with mga driver: X server fails to start without suid wraper.

What does that mean in practice? How many non-KMS drivers are there?
If this mostly affects people with obscure and old HW I'd say it's still worth going the safer route by default and ask those who need it to enable the flag.
Comment 6 Alexander Tsoy 2018-10-26 08:57:35 UTC
(In reply to Alexander Tsoy from comment #3)
> - suid bit is absolutely required for non-KMS video drivers. I Just tested
> GDM with mga driver: X server fails to start without suid wraper.
After some thinking I guess this is because GDM+systemd is a special case. Other display managers probably run X server as root and do not require suid bit.
Comment 7 Vincent de Phily 2018-10-26 14:58:23 UTC
AFAICT the need for setuid should be pretty rare : old-schoolers not using a display manager, and owners of non-mainstream graphic cards. Both of whom should be able to heed an emerge-time message.

I suggest disabling setuid by default, droping the systemd conditional, and adding something along the lines of `elog "X is installed with(out) setuid, which is bad(good) for security but may be needed to start X as non-root of if your have a non-KMS graphic card.` .

For reference (this is probably what prompted this patch but I haven't seen it referenced in b.g.o), CVE-2018-14665 https://lwn.net/Articles/769577/ is a reminder that we shouldn't install X setuid.
Comment 8 Sergey 'L29Ah' Alirzaev 2018-10-27 01:57:39 UTC
Seems like the USE flag was first left out in favour of !systemd by Matt Turner in 1eaaa168373da2f6258680765585f191ca5f953e. Matt, what was wrong with it?
Comment 9 Laszlo Valko 2018-10-27 12:03:53 UTC
I consider this a regression:

$ diff xorg-server-1.19.5-r2.ebuild xorg-server-1.20.3.ebuild | egrep 'IUSE|suid|setuid'
< IUSE="${IUSE_SERVERS} debug +glamor ipv6 libressl minimal selinux +suid systemd tslib +udev unwind xcsecurity"
> IUSE="${IUSE_SERVERS} debug +glamor ipv6 libressl minimal selinux systemd +udev unwind xcsecurity"
<               $(use_enable suid install-setuid)
>               $(use_enable systemd suid-wrapper)
>               $(use_enable !systemd install-setuid)

In 1.19 (and as far as I can remember in all releases in the past 10 years), there WAS a suid use-flag that I could disable. And X works perfectly without setuid as long as you start it as root, which is the case when running from xdm (I'm not even considering using systemd).

IMHO any ebuild installing setuid programs which might provide usable functionality even without actually being setuid should provide such a flag to disable installing the binaries with setuid so that I don't need to manually remove that setuid flag after installing and after every reinstalling the package.
Comment 10 Matt Turner gentoo-dev 2018-10-28 20:27:46 UTC
The story is that we had a IUSE=suid flag and no one knew why. Gentoo has a long history of adding knobs where they're not needed and since I'm maintaining x11@ packages by myself I've tried to reduce the surface area of such configuration options.

There are two configuration options in this area: suid-wrapper and install-setuid. As far as I understand with systemd (or elogind) all configurations work without setuid. Can someone confirm? Comment 3 seems to suggest otherwise: "suid bit is absolutely required for non-KMS video drivers"

It's the other non-systemd/non-elogind case that I don't fully understand.

Can we just require systemd or elogind and never install setuid? That would be simple.

If we offer the IUSE=suid flag again and default it to off when there are configurations that only work when it's on, users will file bugs and I'll have to deal with it. That's what I'm trying to avoid -- I want this to be configurable but not in a way that I'm going to constantly have to explain to people.
Comment 11 Sergey 'L29Ah' Alirzaev 2018-10-28 20:29:46 UTC
(In reply to Matt Turner from comment #10)
> If we offer the IUSE=suid flag again and default it to off when there are
> configurations that only work when it's on, users will file bugs and I'll
> have to deal with it. That's what I'm trying to avoid -- I want this to be
> configurable but not in a way that I'm going to constantly have to explain
> to people.

What's wrong with defaulting to on and using ewarn?
Comment 12 Matt Turner gentoo-dev 2018-10-28 20:37:29 UTC
(In reply to Sergey 'L29Ah' Alirzaev from comment #11)
> (In reply to Matt Turner from comment #10)
> > If we offer the IUSE=suid flag again and default it to off when there are
> > configurations that only work when it's on, users will file bugs and I'll
> > have to deal with it. That's what I'm trying to avoid -- I want this to be
> > configurable but not in a way that I'm going to constantly have to explain
> > to people.
> 
> What's wrong with defaulting to on and using ewarn?

Maybe that's what we'll have to do, but I'm hoping we can do something better than that.
Comment 13 Alexander Tsoy 2018-10-28 20:46:03 UTC
(In reply to Matt Turner from comment #10)
> There are two configuration options in this area: suid-wrapper and
> install-setuid. As far as I understand with systemd (or elogind) all
> configurations work without setuid. Can someone confirm? Comment 3 seems to
> suggest otherwise: "suid bit is absolutely required for non-KMS video
> drivers"
I'm sorry, that was a wrong statement. It's GDM that starts X server under user credentials and require suid bit for non-KMS drivers. Other display managers start X server as root.
Comment 14 Matt Turner gentoo-dev 2018-10-28 20:53:37 UTC
(In reply to Alexander Tsoy from comment #13)
> (In reply to Matt Turner from comment #10)
> > There are two configuration options in this area: suid-wrapper and
> > install-setuid. As far as I understand with systemd (or elogind) all
> > configurations work without setuid. Can someone confirm? Comment 3 seems to
> > suggest otherwise: "suid bit is absolutely required for non-KMS video
> > drivers"
> I'm sorry, that was a wrong statement. It's GDM that starts X server under
> user credentials and require suid bit for non-KMS drivers. Other display
> managers start X server as root.

Thanks. Do I understand correctly that that means there is definitely a case that requires setuid? I.e., we cannot simply require systemd/elogind and never set setuid.
Comment 15 Laszlo Valko 2018-10-28 21:19:28 UTC
(In reply to Matt Turner from comment #14)
> (In reply to Alexander Tsoy from comment #13)
> > (In reply to Matt Turner from comment #10)
> > > There are two configuration options in this area: suid-wrapper and
> > > install-setuid. As far as I understand with systemd (or elogind) all
> > > configurations work without setuid. Can someone confirm? Comment 3 seems to
> > > suggest otherwise: "suid bit is absolutely required for non-KMS video
> > > drivers"
> > I'm sorry, that was a wrong statement. It's GDM that starts X server under
> > user credentials and require suid bit for non-KMS drivers. Other display
> > managers start X server as root.
> 
> Thanks. Do I understand correctly that that means there is definitely a case
> that requires setuid? I.e., we cannot simply require systemd/elogind and
> never set setuid.

There's the very old way of starting X through xinit as a user. That also needs setuid flag.
Comment 16 Matt Turner gentoo-dev 2018-10-28 21:53:59 UTC
(In reply to Laszlo Valko from comment #15)
> (In reply to Matt Turner from comment #14)
> > (In reply to Alexander Tsoy from comment #13)
> > > (In reply to Matt Turner from comment #10)
> > > > There are two configuration options in this area: suid-wrapper and
> > > > install-setuid. As far as I understand with systemd (or elogind) all
> > > > configurations work without setuid. Can someone confirm? Comment 3 seems to
> > > > suggest otherwise: "suid bit is absolutely required for non-KMS video
> > > > drivers"
> > > I'm sorry, that was a wrong statement. It's GDM that starts X server under
> > > user credentials and require suid bit for non-KMS drivers. Other display
> > > managers start X server as root.
> > 
> > Thanks. Do I understand correctly that that means there is definitely a case
> > that requires setuid? I.e., we cannot simply require systemd/elogind and
> > never set setuid.
> 
> There's the very old way of starting X through xinit as a user. That also
> needs setuid flag.

This is what I'm trying to get clarification on: In the way you describe, setuid is required unconditionally for some configuration?

Or is it not required if you're using systemd/elogind?
Comment 17 Laszlo Valko 2018-10-28 22:18:27 UTC
(In reply to Matt Turner from comment #16)
> (In reply to Laszlo Valko from comment #15)
> > There's the very old way of starting X through xinit as a user. That also
> > needs setuid flag.
> 
> This is what I'm trying to get clarification on: In the way you describe,
> setuid is required unconditionally for some configuration?
> 
> Or is it not required if you're using systemd/elogind?

In the way I describe (ie: you want to run X directly as a user, without any daemon/xdm/systemd/whatever help), you need setuid root or a setuid root wrapper, unless you're willing to sudo/su, or unless you're using a hardware whose driver does not need root privs (I don't know which drivers are okay with that).

Systemd has nothing to do with this, as long as you want to start X directly from a user process.
Comment 18 Alexander Tsoy 2018-10-28 23:54:42 UTC
(In reply to Matt Turner from comment #14)
> Thanks. Do I understand correctly that that means there is definitely a case
> that requires setuid? I.e., we cannot simply require systemd/elogind and
> never set setuid.
1. I don't know much about elogind, and currently Xorg lacks elogind integration.
2. systemd manages access to devices, so it is roughly equivalent to adding your user to "video" and "input" groups and playing with udev rules [0]. But non-KMS drivers still requires root privileges, so systemd can't help here.

[0] https://wiki.gentoo.org/wiki/Non_root_Xorg
Comment 19 Alexander Tsoy 2018-10-28 23:59:34 UTC
(In reply to Alexander Tsoy from comment #18)
> 2. systemd manages access to devices, so it is roughly equivalent to adding
> your user to "video" and "input" groups and playing with udev rules [0].
And don't get me wrong. :) By "roughly equivalent" I mean you achieve the same: access to necessary devices by non-privileged user.
Comment 20 Matt Whitlock 2018-10-31 11:29:43 UTC
(In reply to Matt Turner from comment #10)
> Can we just require systemd or elogind and never install setuid? That would
> be simple.

NAK! My system works just fine without systemd, without elogind, and without Xorg suid. That's because I'm using SDDM, which starts X as root. I will hack the x11-base/xorg-server ebuild to remove the needless dependency before I'd consider installing systemd or elogind on my system.
Comment 21 jon R-B 2018-11-01 14:45:02 UTC
(In reply to Matt Whitlock from comment #20)
> (In reply to Matt Turner from comment #10)
> > Can we just require systemd or elogind and never install setuid? That would
> > be simple.
> 
> NAK! My system works just fine without systemd, without elogind, and without
> Xorg suid. That's because I'm using SDDM, which starts X as root. I will
> hack the x11-base/xorg-server ebuild to remove the needless dependency
> before I'd consider installing systemd or elogind on my system.

NAK here as well !  
just sort the damn ebuild. Why would you advocate forcing systemd onto the masses when its track record is soo poor ( https://forums.gentoo.org/viewtopic-t-1088680.html and this just recent history). The irony is a systemd system sets xorg up more secure BUT you get the insecurity and bad practices of systemd.

Now either Gentoo comes out and say it is a systemd only distro (and watch as people leave gentoo and linux) or they just sort the build process out.


-      $(use_enable suid install-setuid) 
... 
+      $(use_enable systemd suid-wrapper) 
+      $(use_enable !systemd install-setuid)
Comment 22 Andreas Sturmlechner gentoo-dev 2018-11-01 14:47:09 UTC
No one forces systemd, please stay reasonable and ontopic for this bug to progress.
Comment 23 Matt Turner gentoo-dev 2018-11-01 21:12:37 UTC
I'm thinking we'll add back IUSE=suid and default it to off. I think that's what the majority of users want.

Maybe then we can modify the few remaining user modesetting drivers to require xorg-server[suid]?

Is that okay with everyone?
Comment 24 Matt Whitlock 2018-11-02 04:11:06 UTC
(In reply to Matt Turner from comment #23)
> I'm thinking we'll add back IUSE=suid and default it to off. I think that's
> what the majority of users want.
> 
> Maybe then we can modify the few remaining user modesetting drivers to
> require xorg-server[suid]?
> 
> Is that okay with everyone?

If I were using a user modesetting driver, I would be annoyed at being forced to install xorg-server with USE="suid" even though I wouldn't need suid since I would only ever have the X server started by a display manager that runs as root. (How many people still seriously log in on the Linux virtual console and run "startx" at the command line?)

I would propose a "suid" USE flag that defaults to off and that the xorg-server ebuild should emit an ewarn if the user has a user modesetting driver enabled in VIDEO_CARDS but has not enabled USE="suid" for xorg-server.

SetUID should be the exception, not the rule, and any package requiring installation of binaries with SetUID root should be viewed with a high degree of suspicion.
Comment 25 Matt Turner gentoo-dev 2018-11-02 05:13:25 UTC
(In reply to Matt Whitlock from comment #24)
> (In reply to Matt Turner from comment #23)
> > I'm thinking we'll add back IUSE=suid and default it to off. I think that's
> > what the majority of users want.
> > 
> > Maybe then we can modify the few remaining user modesetting drivers to
> > require xorg-server[suid]?
> > 
> > Is that okay with everyone?
> 
[snip]
> I would propose a "suid" USE flag that defaults to off 

How is that different from what I said?
Comment 26 Laszlo Valko 2018-11-02 05:16:36 UTC
(In reply to Matt Turner from comment #25)
> (In reply to Matt Whitlock from comment #24)
> > (In reply to Matt Turner from comment #23)
> > > I'm thinking we'll add back IUSE=suid and default it to off. I think that's
> > > what the majority of users want.
> > > 
> > > Maybe then we can modify the few remaining user modesetting drivers to
> > > require xorg-server[suid]?
> > > 
> > > Is that okay with everyone?
> > 
> [snip]
> > I would propose a "suid" USE flag that defaults to off 
> 
> How is that different from what I said?

In that you shouldn't "modify the few remaining user modesetting drivers to require xorg-server[suid]" because that's a bad idea.
Comment 27 Matt Whitlock 2018-11-02 05:17:06 UTC
(In reply to Matt Turner from comment #25)
> (In reply to Matt Whitlock from comment #24)
> > I would propose a "suid" USE flag that defaults to off 
> 
> How is that different from what I said?

That's not the part that's different. But you proposed adding an RDEPEND on x11-base/xorg-server[suid] to the remaining user modesetting drivers. That's the part to which I'd object, given that suid is really only needed in the rare case that someone both uses a user modesetting driver AND wants to start an X server as an unprivileged user. Given the obvious security concerns around having X installed with setuid root, I'd think USE="suid" should be strictly optional.
Comment 28 Larry the Git Cow gentoo-dev 2018-11-02 05:27:59 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92cc7c28132dd325318abd0f1150e96a9e631036

commit 92cc7c28132dd325318abd0f1150e96a9e631036
Author:     Matt Turner <mattst88@gentoo.org>
AuthorDate: 2018-11-02 05:25:17 +0000
Commit:     Matt Turner <mattst88@gentoo.org>
CommitDate: 2018-11-02 05:27:32 +0000

    x11-base/xorg-server: Readd IUSE=suid
    
    Users are particularly unhappy about the inability to control whether
    the Xserver is installed with setuid or not.
    
    Closes: https://bugs.gentoo.org/669648
    Signed-off-by: Matt Turner <mattst88@gentoo.org>

 x11-base/xorg-server/xorg-server-1.20.3.ebuild | 4 ++--
 x11-base/xorg-server/xorg-server-9999.ebuild   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
Comment 29 Matt Turner gentoo-dev 2018-11-02 05:34:36 UTC
I hope you guys will contribute to https://wiki.gentoo.org/wiki/Non_root_Xorg so that we can resolve bug 450364.
Comment 30 Alexander Tsoy 2018-11-02 08:42:30 UTC
(In reply to Matt Turner from comment #23)
> Maybe then we can modify the few remaining user modesetting drivers to
> require xorg-server[suid]?
BTW, suid-wrapper [0] does similar thing at runtime. It checks that all video cards are KMS cards and runs X server as unprivileged user or as root otherwise. But of course it doesn't help with starting X from the console, except for systemd users. ;) So maybe it makes sense to enable suid-wrapper for systemd users if USE=suid.

[0] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/xorg-wrapper.c
Comment 31 Alexander Tsoy 2018-11-02 09:07:50 UTC
How about this? I believe it will be slightly more secure for systemd users.

@@ -163,8 +163,8 @@
                $(use_with doc xmlto)
                $(use_with systemd systemd-daemon)
                $(use_enable systemd systemd-logind)
-               $(use_enable systemd suid-wrapper)
-               $(use_enable suid install-setuid)
+               $(usex suid $(use_enable systemd suid-wrapper) '--disable-suid-wrapper')
+               $(usex suid $(use_enable !systemd install-setuid) '--disable-install-setuid')
                --enable-libdrm
                --sysconfdir="${EPREFIX}"/etc/X11
                --localstatedir="${EPREFIX}"/var
Comment 32 Alexander Tsoy 2018-11-02 09:25:11 UTC
(In reply to Alexander Tsoy from comment #31)
> How about this? I believe it will be slightly more secure for systemd users.
Some clarifications:
1. suid wrapper drops privileges before executing X server, so it looks like recent vulnerabilities don't affect some configurations.
2. I can't think of any case where suid-wrapper won't suffice for systemd users.
3. We definitely don't need both suid-wrapper and suid flag. If the wrapper exists, it will be used anyway (see Xorg shell wrapper).
Comment 33 stqn 2018-11-03 11:40:14 UTC
Well, apparently I’m that one person who starts Xorg by login as a user and typing startx. Thankfully I saw in the update that the suid flag changed and thought it might cause issues, so after I couldn’t start X anymore the first thing I tried (reinstalling xorg-server with +suid) worked.

A warning message would have been nice though.

I don’t know how many people start X with startx, but under Gentoo it seems to me that it shouldn’t be so rare since it means installing and configuring one less package, compared to using a seemingly useless login manager.

Is there a wiki page or something that explains how to best deal with this? I’m not against security fixes but I’m not sure what to do in this case.
Comment 34 Alan Mackenzie 2018-11-03 13:41:31 UTC
Hello, there!

I just got caught out by this change (I start X as a user with `startx', which calls xinit).  My X failed to start, and the error messages were only moderately helpful.  It has taken me several hours to track down what was up.

Yes, I need to set the suid USE flag, which I have now done, and my X now comes up.

But I am somewhat disappointed that:
(i) The ebuild was simply changed without updating the version number, and that this was a significant change, not a minor one.  This prevented me being able to do a diff between the old and new versions.
(ii) There was no NEWS item to warn users like me of the trouble ahead.

May I suggest that it is not to late to issue a NEWS item?
Comment 35 Andreas Sturmlechner gentoo-dev 2018-11-03 16:26:55 UTC
*** Bug 670200 has been marked as a duplicate of this bug. ***
Comment 36 Matt Turner gentoo-dev 2018-11-03 17:18:57 UTC
Matt Whitlock, Laszlo Valko: Do you see my point now?

People who had problems now that xorg-server defaults to USE=-suid: I'm sorry. I had it configured for maximum compatibility. A few months ago I tried to enable the suid-wrapper so we'd get the best of both worlds and it broke someone else's configuration in a way we could never understand. I asked for feedback. I asked for help. No luck.

So I switched to enabling setuid if systemd wasn't enabled, again so that it wouldn't break anyone's configuration.

But that's not good enough (see this bug).

So, I'm sorry. But I'm also really sick of dealing with this.

Can you guys please try the patch in comment 31?
Comment 37 Matt Whitlock 2018-11-03 18:22:31 UTC
I don't know Gentoo's official policy on this: is it better to break some people's systems outright, in a clear and obvious way, or to break everyone's systems in a subtle and insidious way? Introducing security vulnerabilities to fix some edge cases is an example of the latter.

Issue a NEWS item regarding the expected breakage for people who use 'startx', and install X.org without setuid by default. The people with unusual configurations should be the ones to bear the burden of their choices. Of course we should seek to minimize their burden but not at the expense of security for everyone else.
Comment 38 Manfred Knick 2018-11-04 09:51:00 UTC
(In reply to Matt Turner from comment #36)

Cross-Reference: [https://bugs.gentoo.org/670212#c2]
Comment 39 Simon 2018-11-06 21:49:33 UTC
Seems like we have some related/duplicate bugs, but as posted in https://bugs.gentoo.org/670212#c11

Please revert this or default to +suid, this is breaking people's systems

Also massively disagree with what @Matt Whitlock said above, breaking systems is never acceptable over an insecure system.
Apart from that I'm not sure what the real gain is here in that the user who doesn't use systemd/elogind (which I believe are the only current implementations that can somehow manage secure hardware access for users, but come with a bunch of their own vulnerabilities) would still need to be in the right groups, i.e. can still access all hardware.
And for "the people with unusual configurations" (i.e. running systemd on gentoo ;)) let them disable the suid USE flag if they feel it's important. Or alternatively add a systemd or elogind USE flag and only then disable install-suid?

P.S. I'm using openrc + elogind + GDM + GNOME 3.26 and it's not working for me, so not even sure the elogind route properly works.
Comment 40 gevisz@gmail.com 2018-11-08 21:38:52 UTC
(In reply to Matt Whitlock from comment #37)
> I don't know Gentoo's official policy on this: is it better to break some
> people's systems outright, in a clear and obvious way, or to break
> everyone's systems in a subtle and insidious way? Introducing security
> vulnerabilities to fix some edge cases is an example of the latter.
> 
> Issue a NEWS item regarding the expected breakage for people who use
> 'startx', and install X.org without setuid by default. The people with
> unusual configurations should be the ones to bear the burden of their
> choices. Of course we should seek to minimize their burden but not at the
> expense of security for everyone else.

It is the "edge case" and "unusual configuration" to use absolutely useless display managers to start xorg-server when in can be done without a useless package just by using startx command.

So, it is those that use display managers that should "bear the burden of their
choices."

And it is already too late to issue the news about it. Just update https://wiki.gentoo.org/wiki/Non_root_Xorg
Comment 41 gevisz@gmail.com 2018-11-09 19:41:33 UTC
While writting may previous comment, I have not seen a brilliant reply from
Manfred Knick posted here: https://bugs.gentoo.org/670212#c2

I think it should be posted also in this thread. The quote is below.

(In reply to Matt Whitlock from Bug 669648 comment_#37)
                   [https://bugs.gentoo.org/669648#c37]
> I don't know Gentoo's official policy ...
> ... The people with unusual configurations ...       <--- ??? !!!
What the hell should be *unusual*
by using basic elementary KISS     OpenRC | startx | twm ?
Comment 42 Andreas Sturmlechner gentoo-dev 2018-11-09 20:01:27 UTC
Please don't mistake bugzilla with the forums.
Comment 43 Matt Turner gentoo-dev 2018-11-09 20:41:23 UTC
(In reply to Andreas Sturmlechner from comment #42)
> Please don't mistake bugzilla with the forums.

Actually, to be honest I think this is beneficial.

I've argued that "changing xyz is going to break such-and-such configuration" or "this is going to confuse users" to people on both sides of this, and I'm tired of it.

I think the result of this bug/thread is hopefully that people now understand that this just isn't as simple as they'd like to believe. I feel like I now have the evidence to support my earlier claims.



FWIW, it's been suggested to leave the IUSE=suid in place and default to off, but to setgid the Xorg binary to the input group. The expectation is that this will satisfy 95%+ of people. The only people I think that will need the suid USE flag are those using user-modesetting drivers like r128.

Reopening for that change.
Comment 44 Matt Turner gentoo-dev 2018-11-09 21:27:55 UTC
(In reply to Matt Turner from comment #43)
> Reopening for that change.

Actually, we'll do that in bug 670212.
Comment 45 Andreas Sturmlechner gentoo-dev 2018-11-10 21:36:16 UTC
*** Bug 670860 has been marked as a duplicate of this bug. ***