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.

Sign up for GitHub

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

Jump to bottom

Add XAuthorityInSystemDir option #3393

Open
wants to merge 3 commits into
base: devel
Choose a base branch
from
Open

Add XAuthorityInSystemDir option #3393

wants to merge 3 commits into from
+33 −1

Conversation

matt335672
Copy link
Member

Fixes #3383

Add an option to allow XAUTHORITY to be moved away from $HOME.

This is modelled on the lightm 'user-authority-in-system-dir' option, and also current GDM default behaviour.

A minor typo in sesman.ini(5) related to the port setting is also fixed.

@matt335672
Fix minor typo in sesman.ini(5)
b61dfb1
@matt335672
Add XAuthorityInSystemDir option
d2e96fe 
Add an option to allow XAUTHORITY to be moved away from $HOME.

This is modelled on the lightm 'user-authority-in-system-dir' option,
and also current GDM default behaviour.
@matt335672 matt335672 mentioned this pull request Jan 13, 2025
Closed
@matt335672
Copy link
Member Author

@derekschrock - if you've got the time to look at this, it might be useful for you on FreeBSD. Any comments gratefully received.

moobyfr
moobyfr reviewed Jan 13, 2025
View reviewed changes
docs/man/sesman.ini.5.in Outdated
\fBXAuthorityInSystemDir\fR=\fI[no|yes]\fR
If set to \fByes\fR, xrdp will set XAUTHORITY to be in a system directory
(currently @socketdir@/\fI<uid>\fR) which is only accessible to the
logged-in user.
Copy link
Contributor

@moobyfr moobyfr Jan 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps adding "Default to no" to be coherent with the others variables

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @moobyfr..

Now looks like this in an 80 column terminal:-

image

What do you think?

@derekschrock
Copy link
Contributor

Looks good.

Using no xrdp is using ~/.Xauthority
Using yes xrdp is using /var/run/xrdp/<UID>/Xauthority

@tsz8899
Copy link

tsz8899 commented Feb 12, 2025 •
edited
Loading

During the testing of the system environment with LDAP + NFS (homedir) + XRDP server structure, it was found that when the XRDP server is a deepin linux, setting XAuthorityInSystemDir=yes leads to the loss of user authentication information.

When XAuthorityInSystemDir=no, everything works fine. LDAP users can login to the XRDP server, and the user's home directory is on the NFS service.

When XAuthorityInSystemDir=yes, the performance is good, and the impact of restarting NFS on users is reduce.
However, when the desktop is lockscreen, LDAP users are no longer recognized, switch user ldapusername display is ...
and only the local users login box for the XRDP server is displayed. after logging in with a local user, the desktop session returns to the original LDAP user state.

Creating a symbolic link from /var/run/$UID/Xauthority to ~/.Xauthority is ineffective.
This issue does not occur in the debian environment.lockscreen can display ldap user

@matt335672
Copy link
Member Author

Thanks for raising this @tsz8899

I don't fully understand the problem:-

  1. Where is the lockscreen running? on the physical machine, or on the xrdp session?
  2. How is the lockscreen provided? Via gdm, or a separate program like xscreensaver?

It could be the XAUTHORITY hasn't been communicated to the systemd --user instance for the user. Can you see it in systemctl --user show-environment?

@tsz8899
Copy link

tsz8899 commented Feb 18, 2025 •
edited
Loading

The phenomenon occurs within the xrdp session.The issue was found to be caused by an exception from org.deepin.dde.lock in the Deepin system, and it has been reported to the operating system developers.

XAuthorityInSystemDir is working normally in the NFS scenario.

@matt335672
Copy link
Member Author

Thanks for letting us know @tsz8899

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@moobyfr moobyfr moobyfr left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Add support for a private xauth file
4 participants
@matt335672 @derekschrock @tsz8899 @moobyfr