Bug 1450720
| Summary: | Fedora-25 XRDP-0.9.2 [Xorg] selection results in single color unresponsive screen | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Charles Butterfield <cb20777> |
| Component: | xrdp | Assignee: | Itamar Reis Peixoto <itamar> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | bazanluis20, bojan, cb20777, itamar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-12-12 10:55:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Charles Butterfield
2017-05-15 02:50:56 UTC
Do you have SELinux enabled? If so, is xrdp-selinux package installed? The log file will generally be in the home directory for xorgxrdp. The system has SELINUX=Permissive. I'll take another look for the log files when I get home. Okay, I've figured out the problem(s), and a temporary workaround. 1) There is no logfile. Instead /bin/Xorg is launching Xorg.wrapper which outputs an error message and quits. It never launches the /usr/libexec/Xorg and so the -logfile argument is never used. 2) The Xorg error message is "/usr/libexec/Xorg.wrap: Only console users are allowed to run the X server". So apparently Xorg.wrap is enforcing an access control policy. However (as discussed below) my user CAN login to the console. 3) Workaround: create /etc/X11/Xwrapper.config and add the following line: allowed_users = anybody. On my system (Fedora-25) there is no Xwrapper.config and apparently the default behavior is as if "allowed_users = console" was specified. I have no idea how Xorg.wrap is making this determination. In point of fact, the account I am using IS able to login to the console, although it is NOT a local account but rather an Active Directory account. I modified /etc/sssd/sssd.conf to allow that AD account to login via the console, SSH, etc. Caution - I have TWO similar Fedora-25 systems. The original problem was reported on my HOME system, which is NOT joined to a domain. Today I was able to reproduce what SEEMS to be the same problem on my WORK machine which IS joined to a domain. The analysis and workaround reported in Comment 3 above is from my WORK (domain) machine. Tonight I'll see if the problem and workaround are the same on my HOME (non-domain) machine and report my findings. Lastly, I now have access to 2 different session types: Xvnc and Xorg. Where can I go to figure out the PROs and CONs of the two session types? This is a subset of my earlier more general question about the current status of the commented out sections (i.e. are they useful, are they really old obsolete stuff, or what? Also what do some of the more obscure options mean - such as "code", etc). Any insight you can offer (such as a pointer to some wiki) would be appreciated. (In reply to Charles Butterfield from comment #3) > 3) Workaround: create /etc/X11/Xwrapper.config and add the following line: > allowed_users = anybody. This is documented in /usr/share/doc/xrdp/README.Fedora. (In reply to Charles Butterfield from comment #4) > Lastly, I now have access to 2 different session types: Xvnc and Xorg. > Where can I go to figure out the PROs and CONs of the two session types? > This is a subset of my earlier more general question about the current > status of the commented out sections (i.e. are they useful, are they really > old obsolete stuff, or what? Also what do some of the more obscure options > mean - such as "code", etc). Any insight you can offer (such as a pointer > to some wiki) would be appreciated. Xorg is a new thing and not yet overly mature. It is supposed to be better in the long run, because it supports dynamic resizing etc. I found it a bit rough around the edges (the pointer seems to be lagging), so YMMV. Xvnc is the old and "proven" thing. 1) Yes, I see now. Sorry, I didn't think to look there (/usr/share/doc). I was focusing on the man page and the config files themselves. 2) Thanks for the info about Xorg vs Xvnc. 3) In my earlier comments I assumed that "console" meant "authorized to login to the console" rather that "currently logged into the console". The later seems really odd. That confusion was why I was thinking domain vs non-domain was relevant. I see now that it is not. 4) The default behavior of Xorg w.r.t. requiring the user to be CURRENTLY logged into the console seems so odd (and counter productive) that I'm thinking of filing a bug report about it to the Xorg group. Does that seem to make sense to you? Surely this must affect any software that wants to create a virtual framebuffer using Xorg software. (In reply to Charles Butterfield from comment #7) > 4) The default behavior of Xorg w.r.t. requiring the user to be CURRENTLY > logged into the console seems so odd (and counter productive) that I'm > thinking of filing a bug report about it to the Xorg group. Does that seem > to make sense to you? Surely this must affect any software that wants to > create a virtual framebuffer using Xorg software. I guess the intention (from reading the manual page) was to distinguish between users with physical access to the system and the ones without. As such, I guess it works as expected. Now, whether that's a bug, I honestly have no idea... FYI - I just created the related https://bugzilla.redhat.com/show_bug.cgi?id=1451518 assigned to "xorg-x11-server" inquiring about changing the default from "allowed_users=console" to "allowed_users=anybody". Not sure what their posture will be, but it would seem to make sense to "fix" the issue at the source (unless the fix is inherently dangerous) rather than in each package that uses a virtual framebuffer, or worse, by each user of a virtual framebuffer. 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. 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. |