Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into workaround(s) for X permissions issue #1805

Closed
joolswills opened this issue Dec 27, 2016 · 2 comments

Comments

Projects
None yet
1 participant
@joolswills
Copy link
Member

commented Dec 27, 2016

@joolswills joolswills self-assigned this Dec 27, 2016

@joolswills

This comment has been minimized.

Copy link
Member Author

commented Dec 27, 2016

Related issues

https://bugzilla.redhat.com/show_bug.cgi?id=1177513
https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1562219

Note that running startx 2>myerror.log from terminal fails without the startx patch from the redhat bugtracker. It isn't enough to fix it when launching from ES though as it will get a permission denied on /dev/vt0. - might be able to use openvt or something as a workaround (want to avoid adjusting vt permissions which has been a suggested workaround - but it's possibly the simplest solution)

@joolswills

This comment has been minimized.

Copy link
Member Author

commented Dec 27, 2016

Have a solution.

With the older xserver and the xwrapper we were able to allow anybody to start X. Now we can't do that - but we can start X on the TTY/VT that we were logged in on that ES was launched from. We can save that before launching ES (because when ES is launched, it is not attached to a tty), and then pass it in to xinit or startx on launch via runcommand.

for example instead of startx we do startx -- vt1 -keeptty

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.