| Summary: | No XDMCP in Mageia 7.1 & Cauldron either xdm, gdm or lightdm | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Mia Pienitz <mia> |
| Component: | RPM Packages | Assignee: | Aurelien Oudelet <ouaurelien> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, olav, ouaurelien, yvesbrungard |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://gitlab.gnome.org/GNOME/gdm/-/issues/625 | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
|
Description
Mia Pienitz
2020-08-27 14:11:54 CEST
Hi, Thanks reporting you get some troubles with our distribution. We do not support XDMCP as it leaves a Mageia systems to security issues, without properly configuration. It is deactivated. Running a X server (as root) throught a network without doing a ssh connection is not best practices. Have you ever tried a VNC server and client? We think this should runs better. Could you also attach a copy of "/var/log/Xorg.0.log" here when attempting remote connections, for forensics? XDMCP on GDM is disabled by default upstream. It seems to rely on tcp-wrappers. If that is not explicitly enabled it will not enable XDMCP. Mageia nor Fedora enables that. Tcp_wrappers is IMO outdated, not maintained and should not be relied upon. See e.g. the history of tcp_wrappers: http://svnweb.mageia.org/packages/cauldron/tcp_wrappers/current/SPECS/tcp_wrappers.spec?view=log. For almost 10 years there hasn't been any new version. CC:
(none) =>
olav I filed a bug with GDM regarding the unclear documentation. Though possibly they could reconsider why it relies on tcp_wrapper. Maybe there's a systemd thing. I've added that thought as a PS. See Also:
(none) =>
https://gitlab.gnome.org/GNOME/gdm/-/issues/625 Thanks Olav for your wisdom. I was prone to close this. But, leaving this in Bugsquad for several weeks, before: or closing, or assigning to pkg maintainers. @ Mia Pienitz, After some discuss on our dev IRC, there is a setting in our MSEC tool to allow X connections throught network. Can you please see it in MCC => Security => Configure system security, permissions, audit => Security Settings => System security and there is a key named: ALLOW_X_SERVER_TO_LISTEN Should be ON to work. (In reply to Aurelien Oudelet from comment #1) > Hi, > Thanks reporting you get some troubles with our distribution. > > We do not support XDMCP as it leaves a Mageia systems to security issues, > without properly configuration. It is deactivated. Deactivating is not a problem, than it can be activated again. > Running a X server (as root) throught a network without doing a ssh > connection is not best practices. Well, in a little developer network behind some firewalls shouldn't be a problem. I think I can handle it. ;) > > Have you ever tried a VNC server and client? > We think this should runs better. > It integrates not so well. Try multiwindow. Or in other words, VNC RDP or whatever is to connect remotely to a machine. With XDMCP you can have a seamless integration of two desktops in one. > Could you also attach a copy of "/var/log/Xorg.0.log" here when attempting > remote connections, for forensics? With which DM? (In reply to Aurelien Oudelet from comment #5) > @ Mia Pienitz, > > After some discuss on our dev IRC, there is a setting in our MSEC tool to > allow X connections throught network. > Can you please see it in MCC => Security => Configure system security, > permissions, audit => Security Settings => System security and there is a > key named: > > ALLOW_X_SERVER_TO_LISTEN > > Should be ON to work. xdm: Did it, reboot, nothing changed. At the same time I had a look at the Xorg.0.log: during the time of connection, no new entries.
Aurelien Oudelet
2020-09-02 17:51:49 CEST
CC:
(none) =>
ouaurelien Hello, The variable name in msec is ALLOW_XSERVER_TO_LISTEN. It manages at least gdm and SDDM. It seems that you have also to open ports 177 UDP CC:
(none) =>
yves.brungard_mageia Status of this BR? The msec utility will change the parameters used when starting xorg to allow X server to accept connections from network on tcp port 6000. netstat will show that there is a process listening on the port. It doesn't show whether or not shorewall will allow the packets in. To ensure all traffic that originates within the lan will be accepted, add the following four lines to /etc/shorewall/rules.drakx ... # head -n 4 /etc/shorewall/rules.drakx ACCEPT net:10.0.0.0/8 fw ACCEPT net:169.254.0.0/16 fw ACCEPT net:172.16.0.0/12 fw ACCEPT net:192.168.0.0/16 fw This ensures that no matter what range the router uses for the lan, all traffic will be accepted. Don't use this on a device that will be used on an untrusted network. Don't use drakfirewall after that to make any changes or those lines will be removed. CC:
(none) =>
davidwhodgins Reporter, could you please reply to the previous question? If you don't reply within two weeks from now, I will have to close this bug as OLD. Thank you. Keywords:
(none) =>
NEEDINFO (In reply to papoteur from comment #8) > Hello, > The variable name in msec is ALLOW_XSERVER_TO_LISTEN. > It manages at least gdm and SDDM. > It seems that you have also to open ports 177 UDP No, as per https://github.com/sddm/sddm/issues/1180 sddm will not have any XDMCP support which many major distros will ditch when wayland stuff will be the default window system. Anyway, the recommended Display Manager which can handle XDMCP under Mageia is: LightDM. To enable it, you must do: 1. Modify /etc/lightdm/lightdm.conf 2. add: [XDMCPServer] enabled=true port=177 3. On a headless system, disable the automatic start of one seat so that LightDM can run in the background: [LightDM] start-default-seat=false 4. Enable X server XDMCP support under MSEC by activating the variable: ALLOW_XSERVER_TO_LISTEN 5. Open firewall (default is shorewall) with the 117 port. Also, you can accept local LAN traffic by enabling it by editing as root: /etc/shorewall/rules ACCEPT net:10.0.0.0/8 fw ACCEPT net:169.254.0.0/16 fw ACCEPT net:172.16.0.0/12 fw ACCEPT net:192.168.0.0/16 fw Closing this, as this is tested OK. Feel free to repoen in case of still difficulties. Status:
NEEDINFO =>
RESOLVED |