Bug 1078902 - Xorg without root rights
Summary: Xorg without root rights
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Reznik
QA Contact:
URL:
Whiteboard: ChangeAcceptedF21 SystemWideChange
Depends On: 1078808 1078789 1078810
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-20 14:02 UTC by Jaroslav Reznik
Modified: 2019-08-19 07:37 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 10:20:02 UTC
Type: ---
Embargoed:
pbokoc: fedora_requires_release_note-


Attachments (Terms of Use)
Xorg log failing with needs_root_rights = auto (6.18 KB, text/plain)
2014-12-25 10:08 UTC, Andrew
no flags Details
Test script output for a failed launch (6.03 KB, text/plain)
2014-12-25 20:12 UTC, Andrew
no flags Details
kcalc fails to render (151.93 KB, image/png)
2015-01-08 20:02 UTC, Andrew
no flags Details

Description Jaroslav Reznik 2014-03-20 14:02:17 UTC
This is a tracking bug for Change: Xorg without root rights
For more details, see: http://fedoraproject.org//wiki/Changes/XorgWithoutRootRights

The Xorg xserver is a large piece of software which currently runs as root, making it a potential vector for attacks against the system. With recent changes made to systemd-logind it is possible for the xserver to let systemd-logind do device management for it, at which point the xserver will no longer need root rights. Initially this will likely be implemented as the xserver dropping root rights early on.

Comment 1 Jaroslav Reznik 2014-07-04 10:43:34 UTC
This message is a reminder that Fedora 21 Accepted Changes Freeze Deadline is on 2014-07-08 [1].

At this point, all accepted Changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Freeze.

This bug should be set to the MODIFIED state to indicate that it achieved completeness. Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution. For Changes you decide to cancel/move to the next release, please use the NEW status and set needinfo on me and it will be acted upon. 

In case of any questions, don't hesitate to ask Wrangler (jreznik). Thank you.

[1] https://fedoraproject.org/wiki/Releases/21/Schedule

Comment 2 Hans de Goede 2014-07-04 10:47:22 UTC
Hi,

Not sure what to do with this bug, all the necessary Xorg bits have long landed, but the only way to run the Xserver as non-root atm is through startx from a text console, as all the display-managers are not ready yet. It might be best to move this to F-22 from a feature pov.

Regards,

Hans

Comment 3 Jaroslav Reznik 2014-07-04 11:04:37 UTC
Hi,
thank you for reply. From a feature and (probably even more) from users pov, it makes sense to move it to Fedora 22. I'll make sure all places are correctly updated to reflect it.

Comment 4 Andrew 2014-07-04 13:28:02 UTC
Is it possible to leave it for F-21 with startx only? I know I'm a minority here, but that's the way I use. Being done this way it might help to test Xorg in this mode before enabling it for a broader audience.

Comment 5 Hans de Goede 2014-07-04 13:39:13 UTC
(In reply to Andrew Travneff from comment #4)
> Is it possible to leave it for F-21 with startx only? I know I'm a minority
> here, but that's the way I use. Being done this way it might help to test
> Xorg in this mode before enabling it for a broader audience.

For use with startx it requires a tiny bit of manual configuration (because otherwise various dm-s would be broken), see: http://hansdegoede.livejournal.com/14446.html

Other then that all the necessary functionality is there, and there is no intention to remove it.

Comment 6 Andrew 2014-07-04 14:22:12 UTC
Wow, thanks! Just in case, is it planned to make the same thing available for F-20?

Comment 7 Hans de Goede 2014-07-04 15:25:15 UTC
(In reply to Andrew Travneff from comment #6)
> Wow, thanks! Just in case, is it planned to make the same thing available
> for F-20?

No.

Comment 8 Petr Bokoc 2014-10-20 15:17:12 UTC
Change moved to F22, so I'm setting the relnotes flag to - for F21.

Comment 9 Andrew 2014-12-25 10:08:57 UTC
Created attachment 972965 [details]
Xorg log failing with needs_root_rights = auto

Tried it on F21, unsuccessfully.
xorg log tells this:

> Fatal server error: xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted

$ ll /etc/X11/Xwrapper.config
-rw-r--r--. 1 root root 25 Dec 24 20:13 /etc/X11/Xwrapper.config

$ cat /etc/X11/Xwrapper.config
needs_root_rights = auto

Selinux mode: permissive

$ rpm -qa \*xorg\*
xorg-x11-drv-fbdev-0.4.3-19.fc21.x86_64
xorg-x11-drv-modesetting-0.9.0-2.fc21.x86_64
xorg-x11-xkb-utils-7.7-12.fc21.x86_64
xorg-x11-xauth-1.0.9-2.fc21.x86_64
xorg-x11-font-utils-7.5-25.fc21.x86_64
xorg-x11-xinit-1.3.4-2.fc21.x86_64
xorg-x11-drv-evdev-2.9.0-3.fc21.x86_64
xorg-x11-drv-synaptics-1.8.0-9.fc21.x86_64
xorg-x11-server-common-1.16.2.901-1.fc21.x86_64
xorg-x11-fonts-ISO8859-1-100dpi-7.5-14.fc21.noarch
xorg-x11-fonts-Type1-7.5-14.fc21.noarch
xorg-x11-drv-vesa-2.3.2-19.fc21.x86_64
xorg-x11-drv-intel-2.99.916-3.20141117.fc21.x86_64
xorg-x11-utils-7.5-16.fc21.x86_64
xorg-x11-server-utils-7.7-10.fc21.x86_64
xorg-x11-server-Xorg-1.16.2.901-1.fc21.x86_64

Comment 10 Hans de Goede 2014-12-25 10:19:22 UTC
Hi,

(In reply to Andrew Travneff from comment #9)
> Created attachment 972965 [details]
> Xorg log failing with needs_root_rights = auto

How are you starting X ? Unless you're using startx from  a text console this failure is expected to happen since most display managers do not start the Xserver in a properly setup session (such as logging into a text console will give you), and without a proper session X cannot talk to systemd-logind.

Which is why we're carrying this patch:

http://pkgs.fedoraproject.org/cgit/xorg-x11-server.git/tree/0001-Fedora-hack-Make-the-suid-root-wrapper-always-start-.patch

And why the "Xorg without root rights" feature has been pushed back to F-22. With your custom 
Xwrapper.config you're overriding the default selected by that patch, causing the problem you are seeing.

Regards,

Hans

Comment 11 Andrew 2014-12-25 10:32:03 UTC
Thank you. I think it corresponds with my understanding. I launch startx[1] on tty1 with no X running. Will try to make more convincing proof today.

1: more precisely, it is:
startx -- -verbose 7 -logverbose 7 &> /var/tmp/my_xorg.log

Comment 12 Andrew 2014-12-25 10:36:47 UTC
Just in case: I think I have no DM installed.
startx from a text console is my usual workflow.

Comment 13 Andrew 2014-12-25 20:12:38 UTC
Created attachment 973072 [details]
Test script output for a failed launch

OK, more details here. Created a test script[1] and executed following:

a. Logout from X. It was launched by startx, so logoff switches me to the text console.

b. Move Xwrapper.config to its place.

c. Run the test script: ". /tmp/xtest"

Output is attached. Just inserted some empty lines for easier reading.
Note additional errors (actually warnings) about KDSETMODE and VT_SETMODE.
Similar Xorg.0.log attached above.

1:
{ tty
PS_FORMAT=comm,args ps -e | grep /X
ll /etc/X11/Xwrapper.config
cat /etc/X11/Xwrapper.config
grep EE ~/.local/share/xorg/Xorg.0.log
startx -- -verbose 7 -logverbose 7
grep EE ~/.local/share/xorg/Xorg.0.log
} &> /tmp/xout.txt

Comment 14 Hans de Goede 2014-12-25 22:57:28 UTC
(In reply to Andrew Travneff from comment #13)
> 1:
> { tty
> PS_FORMAT=comm,args ps -e | grep /X
> ll /etc/X11/Xwrapper.config
> cat /etc/X11/Xwrapper.config
> grep EE ~/.local/share/xorg/Xorg.0.log
> startx -- -verbose 7 -logverbose 7
> grep EE ~/.local/share/xorg/Xorg.0.log
> } &> /tmp/xout.txt

Hmm, that is likely confusing Xorg because you're decoupling its stdin & stdout from the tty it is running from, can you try doing a simple:

"startx"

Without any input / output redirection directly from a login on tty1 ?

Comment 15 Andrew 2014-12-26 09:59:20 UTC
That's it, thanks. Second X session seems launched without root rigths.
Would it be better to open a separate issue about streams redrection breaking this functionality?

$ PS_FORMAT=uid,gid,comm,args ps -e | grep /X
 1000  1000 xinit           xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :0 -verbose 7 -logverbose 7 vt1 -nolisten tcp -auth /home/andrew/.serverauth.1095
    0  1000 Xorg.bin        /usr/libexec/Xorg.bin :0 -verbose 7 -logverbose 7 vt1 -nolisten tcp -auth /home/andrew/.serverauth.1095
 1000  1000 ssh-agent       /usr/bin/ssh-agent /etc/X11/xinit/Xclients
 1000  1000 xinit           xinit /etc/X11/xinit/xinitrc -- /usr/bin/X :1 vt2 -nolisten tcp -auth /home/andrew/.serverauth.2580
 1000  1000 Xorg.bin        /usr/libexec/Xorg.bin :1 vt2 -nolisten tcp -auth /home/andrew/.serverauth.2580
 1000  1000 ssh-agent       /usr/bin/ssh-agent /etc/X11/xinit/Xclients
 1000  1000 grep            grep --color /X

Comment 16 Hans de Goede 2014-12-26 10:45:23 UTC
(In reply to Andrew Travneff from comment #15)
> That's it, thanks. Second X session seems launched without root rigths.
> Would it be better to open a separate issue about streams redrection
> breaking this functionality?

Yes please, component xorg-x11-server and please assign the bug to me. Although I'm not sure if / when I'll get around to fixing that. Note you should be able to redirect any 2 streams, as long as you leave one connected to the tty, e.g.:

startx &> logfile

Should work fine, likewise redirecting stdin, but leaving stdout and/or stderr connected to the tty should
work fine. Note redirecting one of the streams to *another tty* will breaks things, but if you redirect to regular files and leave one stream unredirected things should work.

Comment 17 Andrew 2014-12-28 11:48:35 UTC
(In reply to Hans de Goede from comment #16)

> Note you should be able to redirect any 2 streams, as long as you leave one connected to the tty

Sorry, seems like it is more restrictive. Described it in rhbz#1177513
Don't see an ability to (re)assign a ticket and can't link it here as "see also".

Comment 18 Andrew 2015-01-08 20:02:05 UTC
Created attachment 977933 [details]
kcalc fails to render

OK, another issue here. Can't use some GUI apps launched in root session ("su - root" in Konsole) with subject feature. Example screenshot attached.
Removing Xwrapper.config seems fixing that.

Comment 19 Bastiaan Jacques 2015-01-15 21:04:21 UTC
(In reply to Hans de Goede from comment #5)
> For use with startx it requires a tiny bit of manual configuration (because
> otherwise various dm-s would be broken), see:
> http://hansdegoede.livejournal.com/14446.html

I've followed these instructions on several machines and it seems to work well, in that `ps' shows Xorg.bin running as the user that started it, except for the following.

If I understand correctly, it should be possible for several users, or a single user, to run multiple X servers simultaneously without root privileges. But this doesn't work on two systems that I've tried, using startx, logging output:

[1650443.633] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
[1650443.634] _XSERVTransMakeAllCOTSServerListeners: server already running
[1650443.634] (EE) 
Fatal server error:
[1650443.634] (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) 
[1650443.634] (EE) 
Please consult the Fedora Project support 

Am I missing something?

Comment 20 Hans de Goede 2015-01-16 08:19:57 UTC
(In reply to Bastiaan Jacques from comment #19)
> (In reply to Hans de Goede from comment #5)
> > For use with startx it requires a tiny bit of manual configuration (because
> > otherwise various dm-s would be broken), see:
> > http://hansdegoede.livejournal.com/14446.html
> 
> I've followed these instructions on several machines and it seems to work
> well, in that `ps' shows Xorg.bin running as the user that started it,
> except for the following.
> 
> If I understand correctly, it should be possible for several users, or a
> single user, to run multiple X servers simultaneously without root
> privileges. But this doesn't work on two systems that I've tried, using
> startx, logging output:
> 
> [1650443.633] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener()
> failed
> [1650443.634] _XSERVTransMakeAllCOTSServerListeners: server already running
> [1650443.634] (EE) 
> Fatal server error:
> [1650443.634] (EE) Cannot establish any listening sockets - Make sure an X
> server isn't already running(EE) 
> [1650443.634] (EE) 
> Please consult the Fedora Project support 
> 
> Am I missing something?

You should be able to do what you want by starting the 2nd xserver like this:

startx -- :1

And the 3th:

startx -- :2

etc.

Comment 21 Bastiaan Jacques 2015-01-16 12:17:12 UTC
That works, thanks!

Comment 22 Andrew 2015-01-26 08:31:19 UTC
Installed xorg-x11-xinit-1.3.4-3.fc21.x86_64, now "&>" works for me w/o -keeptty

As for root apps issue (comment #18)—does it want a separate ticket?

Comment 23 Hans de Goede 2015-01-26 10:03:30 UTC
(In reply to Andrew Travneff from comment #22)
> Installed xorg-x11-xinit-1.3.4-3.fc21.x86_64, now "&>" works for me w/o
> -keeptty
> 
> As for root apps issue (comment #18)—does it want a separate ticket?

Ah I missed that comment, yes file a separate bug for that please, and assign it to me directly from the new bug screen.

I need to discuss this on the upstream xorg-devel list, in a way it is more of a feature then a bug really, the problem is that with the xserver running as user it cannot access shared-memory segments created by other users, such as the root user. One could argue that this is a qt/kde bug. I've written MIT SHM code in the past, and one should check the xshm-attach succeeds (it will also fail when running over the network) and when it does not fail, qt/kde should fallback to not using shm, which it clearly is not doing.

So now the question to discuss upstream becomes if we can do anything to make shm work in this case, or if we simply tell the qt/kde guys to fix their stuff.

Comment 24 Andrew 2015-01-26 15:03:51 UTC
Created RHBZ#1185893
Can't manipulate assignment, sorry.

Comment 25 Jaroslav Reznik 2015-03-03 15:36:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 26 Jan Kurik 2016-07-26 04:26:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 27 Fedora End Of Life 2017-11-16 19:51:44 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 28 Fedora End Of Life 2017-12-12 10:20:02 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.