[SOLVED] xorg-server-1.19.5-r1 suid use-flag removal

[Mazumoto]

Hello gentoorians

Yesterday when updating my ~amd64 sytem portage pulled in xorg-server-1.19.5-r1. After the update, startx doesn't bring up the X server anymore:

[Jaglover]

My X actually starts with

[Mazumoto]

As I mentioned - "startx -- vt1" doesn't work for me ...

[proteusx]

Same problem here. I wish they'd give some warning when they do this s@#t..
I masked =x11-xorg-server-1.19.5-r1.
I cannot be bothered to start arsing about with my start up scripts and tty perms for no good reason.

I compared the ebuild of the-r1 version with the 1.19.5 and the only change I see is the removal of the suid option.
May I ask why was this done?

[Josef.95]

Yes, =x11-xorg-server-1.19.5-r1 is now p-masked
see https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7e9f7ca88eeeb4be5c5bfaa4f73cc3ba5c211947

A fresh "emerge --sync" and a xorg-server rebuild (downgrade) should help.

[Mazumoto]

I'm marking as solved for now, since the mask helps.

[NathanZachary]

Just wanted to say that I got hit by this problem today with =x11-base/xorg-server-1.19.99.901. Following the instructions here:
https://wiki.gentoo.org/wiki/Non_root_Xorg

fixed the problem for me.

In particular:

[hariskar]

For me the solutions above do not work.. Any help?

[wrc1944]

I just got this on one Gentoo install. I masked >=x11-xorg-server-1.19.5-r1, but emerge xorg-server complains that =x11-base/xorg-server-1.19.99.901 is masked, and won't downgrade.

What's the solution if you only want to continue using sddm or lightdm?

1. Forget about masking >=x11-xorg-server-1.19.5-r1, and add your user to the /etc/input group, and

2. Create a /etc/udev/rules.d/99-dev-input-group.rules text file, and add the line:

[ct85711]

From my understanding from the bug reports, you also have to add all your users to the input group too. The issue the as mentioned in the bug report, is that it opens a security issue in that any user can monitor the input for that everyone goes through.

Beyond that, personally I am not seeing what good all this hassle for using a wrapper to do the same thing as the suid. As you'd end up setting the wrapper, so xorg is ran as root, for stuff to work properly unless you want no input (which seems to defeat the purpose anyways).

[wrc1944]

Well, I masked >=x11-base/xorg-server-1.19.99.901 and downgraded to x11-xorg-server-1.19.5-r1 (which rebuilt a few other x11 packages and drivers, rebooted and sddm came up, and all is back to normal.

I'm sticking with this xorg-server version with the suid flag as long as possible. For me, this update (?) turned into an "if it ain't broke don't fix it" situation. However I do run ~amd64 systems, so I'm not complaining.

Apparently, as the OP stated the suid flag was removed in xorg-server-1.19.5, it's now back in xorg-server-1.19.5-r1, which is OK by me .
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

[Tony0945]

[Anon-E-moose]

[Tony0945]

[Anon-E-moose]

I'm sure that there are some talented individuals in the dev arena, unfortunately they seem to be buried behind the worthless ones.

But back to the suid thing, as I was pondering it last night.
It would have been easy to make the suid flag be an either/or for install-setuid or the wrapper route.
It was set on (+) by default, which does install-setuid (the old way)
but they could have simply set it to off (-/remove the +) by default.

Suid off, uses the wrapper (default install, which is probably what most would want, especially gnome/kde folks)
Suid on, does the old install-setuid

Then everyone would have been able to use the ebuild without any modifications or threads started about "what happened to suid, etc"
Well, if they had done this, then all they would have needed to do was put out a news article.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[NathanZachary]

I think that the worst part is that there wasn't a news item about it. I don't mind procedure changes, but I need to know about them.
_________________
“Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---

[skellr]

Xorg upgrades in the testing branch are prone to cause problems. You guys have been around long enough to have seen it more than once right?
Make a backup/snapshot so you can revert the damage until you have time to deal with it.

Shouldn't the "testing" community be helping the developers instead of crying about breakage? Aren't we testing stuff so the "stable" people don't have to deal with it?

[Hu]

Stable user here, so this has not directly impacted any of my systems.

Yes, testing is more susceptible to breakage than stable. However, I tend to agree with the sentiment that NathanZachary expressed. When making a change that is likely to require user intervention on the average system, it would be courteous to include a news item or elog message to warn users that extra work must be done after installing the package.

[blopsalot]

The tree is excellent from an educational perspective, but it is no longer usable from a system administration perspective. Sad really, I popped up thinking they needed help, but they are just rude and have severe tunnel vision. The only thing they need help with is learning the fact that they are all easily replaceable, besides mgorny, zmedico, blueness, etc, the people who have earned the right to be assholes.

oh well, I was a total idiot with ebuilds and portage just a few months ago, now I have a personal tree down to 1061 packages and 73 categories that is more stable then main tree has been in a long time.

[Tony0945]

[blopsalot]

i meant it tongue in cheek. there's many other dev from now and past that I learned alot from. what i mean is I give respect where it's due. i named those because off the top of my head I know portage is not broken, eudev is not broken, etc, but there is no denying that the tree is suffering. bugs are ignored, broken packages remain, interconnected packages are not kept in unison, commits made with disregard for wide range implications, and so on.

[Hu]

[Moderator note: discussion of Meson as a new build dependency moved to RFE: news item for new build dependencies to keep this thread focused on the Xorg USE=suid issues.]

[PrunJuice]

After about 8 hours of debugging I managed to fix my ~mysteriously~ ~suddenly~ broken xorg-server.

Of course now I find this thread after slamming my skull against ever hard surface in a 3 mile radius.

At least i know what caused my issue.

Side note, it seems 1.19.99.901 does not work with modesetting drivers. Had to switch to the frowned upon intel package even after setting up all the needed permissions according to the no suid xorg server guide.

Although the modesetting drivers do work for root even with the testing version. So it must be some extra permissions I don't know how to set causing the problems.

Here is the Xorg log for my failing modesetting config.

Seems like I don't have permissions to "drmSetMaster" on my user account.

[ct85711]

It seems the devs are going for round 2, on forcing on using suid-wrapper. The other interesting part on the ebuild, it forces us to use xorg-x11 for gl and xdm again, because suid-wrapper doesn't work for other stuff still...

[Anon-E-moose]