[Solved] Non root Xorg on AMD video cards

Anon-E-moose · Posted: Mon Aug 03, 2020 9:28 pm Post subject:

I have my user in video, input and tty groups, and I have a small udev rule to change perms on /dev/tty[78] (I might want a second X session sometime)
and startx without parameters, starts on vt7 or 8 if second server.

The Main Man · Posted: Mon Aug 03, 2020 9:52 pm Post subject:

The Main Man · Posted: Mon Aug 03, 2020 11:43 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21605

Adding your user to the tty group has the side effect that you can now write to any user's pseudo-terminal (if they have not run mesg n), and unlike write/wall, there is no forced header/footer. I do not know of a way to exploit this directly, but it could definitely enable mischief in a multi-user system.

The Main Man · Posted: Tue Aug 04, 2020 7:49 am Post subject:

I guess, just wanted to try that if I need it in the future.
I like simple solutions , "startx --vt1" seems simple enough.
The only time I would probably need to switch VT's is if desktop crashed and it's frozen, I would then issue a reboot command on another VT, something like that.
And that works, without adding a user to tty group and having additional udev rules.

Anon-E-moose · Posted: Tue Aug 04, 2020 9:56 am Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21605

Anon-E-moose · Posted: Wed Aug 05, 2020 10:15 am Post subject:

Even better with the kernel 5.8 change, they removed the "ROOT_ONLY" key on the drm set/drop call, which was always available to change, the lock of root only was, um, just a tad too aggressive, especially given the fact that so many other calls to the drm area didn't have that constraint. Anyway with the change then drm_util_master is not needed, any person can use the drm set/drop master calls. As far as older versions, it would be easy enough to change that flag in the source and then recompile the kernel (2 lines within drm_ioctl.c need changing). The nice thing about this way, no need for patches for x11-drivers (modesetting and others) as the patches were there to bypass the need for "root" for those calls, just the simple kernel changes.

The Main Man · Posted: Wed Aug 05, 2020 11:55 am Post subject:

Patching the drivers was to halt the operation of loading video driver and start '/usr/bin/drm_master_util' which only has one function, to set drm master as root, for that it needs 'fd' which it gets from the same patched driver.
Once done the driver continues with the loading.
There was no other way in setups w/o *d's

The whole problem was the decision back then that only root can do that, what were the exact reasons to do that and why is it removed now, would be interesting to find somewhere details about it.

Anon-E-moose · Posted: Wed Aug 05, 2020 12:08 pm Post subject:

Anon-E-moose · Posted: Wed Aug 05, 2020 12:47 pm Post subject:

kajzer, I just applied "0" to the set/drop master define (the same as 5.8.0) to the 5.5.18 kernel I'm running and it works perfectly fine as user, without drm_util_master and associated patches.

**two big thumbs up***

running root-less suid-less wrapper-less *logind-less pam-less AND it all works.

Edit to add: The way I have the use flags for xorg-server set "-systemd -elogind -suid" which give me a server with just normal permissions.
Time to make a quick Doc/tip thread.

_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

The Main Man · Posted: Wed Aug 05, 2020 1:14 pm Post subject:

Great feeling, isn't it?

GDH-gentoo · Posted: Wed Aug 05, 2020 2:28 pm Post subject:

Anon-E-moose · Posted: Wed Aug 05, 2020 2:55 pm Post subject:

Privileged open on devices ie, input, video, tty isn't really a problem on home systems (single or family use) as being in a group or modifying the permissions has no real impact on the system running or security. For business or group working servers, I can see the admin being more restrictive on these things.

So, we have these models each with their own "potential" problems.

suid -- the old fashioned way running as root

wrapper -- just tries to determine whether xorg needs to run as root or not and then starts the server appropriately (theory anyway)

*logind -- gnome way, *logind daemons take care of open on devices as well as set/drop master.

none -- but requires being in a few groups and or permissions set differently (a little more open) on some devices.

---

Running as root is a known risk, so suid is being depreciated
Running with wrapper/*logind just pushes the suid problem further removed from the server (who knows what/if any potential/problems there)
Running with no setting, but changed groups/dev permissions also has potential problems.

Basically pick your poison :lol:

Edit to add: A fix for the input group problem is to do what was mentioned in the butchered non root xorg wiki article

Anon-E-moose · Posted: Wed Aug 05, 2020 4:05 pm Post subject:

Re. changes in drm stuff, this is from drm_auth.c (routines called by set/drop master), interesting comment.

The Main Man · Posted: Wed Aug 05, 2020 9:17 pm Post subject:

Yeah, I found the actual commit

Anon-E-moose, although just changing ROOT_ONLY to 0 works, few more things were also added, keep that in mind.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21605

Anon-E-moose · Posted: Thu Aug 06, 2020 9:13 am Post subject:

Hu, I wonder if the suid-wrapper could be enhanced to do what you envision?
It's not a very big program, starts up, makes a few decisions and then spawn the real Xorg.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Fork-and-drop-root security is something X should've learned to do when it was still called Xfree86, IMO.

Anon-E-moose · Posted: Thu Aug 06, 2020 3:26 pm Post subject: