4

I have a kiosk-style host running Ubuntu Server 14.04. I'm trying to set it up to play some videos, TV-like. Sometimes it needs to play Youtube playlists and other web-based video streaming services etc., so a browser window seems to be necessary.

For this purpose I installed a barebones X.org without a desktop environment and it works.

However, because the administration is over network and the host doubles as a a file and web server (this is a home project), I'm a bit security conscious and I'd like to run X as non-root. I already checked https://wiki.ubuntu.com/X/Rootless, but it seems dated: running X with -nohwaccess complains:

/usr/bin/Xorg vt8 -retro -sharevts -nohwaccess -logfile /tmp/Xorg.U.log :1

...

Fatal server error:
(EE) Unrecognized option: -nohwaccess

If I take the flag off, it starts but fails right away:

Loading extension GLX
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)

Edit: Oops, I can't apparently read! The FATAL error why Xorg terminates is not that, it's this, just after the xf86EnableIOPorts warning:

(--) Depth 24 pixmap format is 32 bpp
Unable to retrieve master
Fatal server error:
[ 38106.045] (EE) AddScreen/ScreenInit failed for driver 0

Whereas running with sudo, it emits:

(--) Depth 24 pixmap format is 32 bpp
RADEON(0): [DRI2] Setup complete
... and so forth.

It seems like a permission problem, but I've set all the rights mentioned in the wiki article:

videoplayer@yuunagi:/usr/bin$ ls -la /dev/tty8
crw-rw---- 1 videoplayer root 4, 8  1月 13 02:09 /dev/tty8 

/dev/event/* have o+rw set,

The user videoplayer belongs to both video and audio groups:

videoplayer@yuunagi:/usr/bin$ cat /etc/group | grep videoplayer
audio:x:29:videoplayer
video:x:44:videoplayer
videoplayer:x:999:

What I am missing here?

Edit: Btw. before anybody points it out: I have KMS enabled. Kernel log says so, (open-source Radeon drivers with DRM in function) and X.org logs says so: [KMS] Kernel modesetting enabled.

Edit2: strace reveals the following:

Opening a GPU device file succeeds:

open("/dev/dri/card0", O_RDWR)          = 9

After that, there's tens of succeeding ioctrls to that file, like this:

ioctl(9, 0xc0106407, 0x7fff66772190)    = 0

And then, last succeeding ioctl:

ioctl(9, TUNER_SET_CONFIG, 0x7fff667722b0) = 0

After that, a fail:

ioctl(9, 0x641e, 0)  = -1 EACCES (Permission denied)
Unable to retrieve master

Btw. the accessed GPU dev file has following permissions:

videoplayer@yuunagi:/usr/bin$ ls -la /dev/dri/card0
crw-rw----+ 1 root video 226, 0  1月 13 02:09 /dev/dri/card0
  • there is no need of root to run X. -A- what is you run-level ? ( who -r ) -B- can you run X as root ? – Archemar Jan 13 '15 at 12:50
  • Unless I'm mistaken, there is indeed no need to run startx as root, but a- the SUID bit of Xorg is set by default, it will run as root. – GolDDranks Jan 13 '15 at 13:17
  • A) My run-level is run-level 2 2015-01-13 02:09. B) I can run X as root. Also: I could start X as non-root before, but after chmodding off the SUID bit, I'm not able to do that. – GolDDranks Jan 13 '15 at 13:29
  • I asked about run-level because I think at run-level 3, X is started. Next if you chnaged permission on X binary, you should delete and reinstall package. (rpm -e ; rpm -i ). – Archemar Jan 13 '15 at 15:11
  • Uhh... Why should I do that? I think that's gonna reset the permission without doing anything else...? Also, Ubuntu is configured for: "Runlevel 2: Graphical multi-user with networking". Runlevel 3 is unused. – GolDDranks Jan 13 '15 at 15:15
3

I'll take a quick guess it depends on some DRI devices. It might also depend on the ability to muck around with PCI memory ranges and things like that, and making those readable by the Xorg user would do more harm to security than having X be non-root. So, securing X by having it run non-root might not actually improve security (thought it could make an attack much harder by blocking the obvious attacks. Who actually knows how to attack a system through its PCI registers?)

But the way I would find the answer is running Xorg under strace.

strace -e trace=open,ioctl Xorg

Then look for which device it tries to open or which operation that fails. (I'm guessing it will be open or ioctl, but you might have to expand that list of syscalls)

0

I have hit the same problem (also with a radeon), and I traced this through the Xorg and kernel sources. My conclusion is that this won't (likely ever) work without the accursed systemd. See this archived email for the code pointers:

Re: X w/o suid root

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.