| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
as some operating system such as FreeBSD searches not only `/etc/pam.d`
but also `/usr/local/etc/pam.d` [1].
[1] https://www.freebsd.org/cgi/man.cgi?query=pam.d&sektion=5
|
| |
|
| |
|
| |
|
|
|
|
| |
as existing xrdp-sesman.unix doesn't suit FreeBSD.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you run xrdp with a Unix Domain Socket (UDS) for the port specified in
/etc/xrdp/xrdp.ini then only root can connect to it.
Test case:
1. Edit /etc/xrdp/xrdp.ini to set "port=/var/run/xrdp-local.socket".
2. Restart xrdp.
3. Run the following, as a non-root user.
socat TCP-LISTEN:12345 UNIX-CONNECT:/var/run/xrdp-local.socket &
rdesktop localhost:12345
Expected behaviour: rdesktop starts up and displays the logon dialog.
Observed behaviour: rdesktop exits with "ERROR: Connection closed" and
socat exits with "Permission denied". (But it suceeds if root runs
socat.)
UDS files are created by trans_listen_address() and given permissions
0660, so only root can connect to it. In this case, for the RDP client
connection, it it fine for any user to connect so it should be given
permissions 0666.
Note that this is only relevant when the port in /etc/xrdp/xrdp.ini has
been set to create a UDS instead of a TCP socket. When a TCP port is
created any user (including remote users, unless the loopback interface
is used) can connect so this is not less secure.
|
|
|
|
| |
lacks a trailing /
|
| |
|
| |
|
|
|
|
| |
Rename g_mk_temp_dir to g_mk_socket_path
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
before try to create a domain socket.
Originally proposed by Ian Geiser (geiseri).
|
| |
|
|
|
|
| |
process
|
| |
|
|
|
|
|
| |
Pointed out by: andrecbarros
Closes: #803
|
| |
|
| |
|
|
|
|
| |
Should fix #755.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test case: On a system running xrdp with no sessions running run:
xrdp-sesadmin -u=<user> -p=<password> -c=list
Expected result: "No sessions." (ignoring debug output)
Observed result: "Error getting session list."
In the SCP_SERVER_STATE_MNG_LISTREQ case in scp_v1_mng_process() if
there are no sessions it ends the scp session, which causes an error in
the client. In commit 0017081d the client was changed to report errors,
giving the result above.
Fix by calling scp_v1s_mng_list_sessions() from scp_v1_mng_process()
even when there are no sessions, and if so sending a packet with a count
of zero so that the client gets what it expects.
|
|
|
|
|
| |
since unavailability of ssl protocols defined in config file
may weaken security and it is important for users.
|
| |
|
| |
|
|
|
|
|
| |
since xrdp-chansrv may be run multiple instances per user. For example,
Xvnc backend creates one session per screen geometry.
|
|
|
|
| |
it is the latest stable branch.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
as it was undocumented and few people know reconnectwm.sh is executed on
client reconnect. The behaviour of startwm.sh / reconnectwm.sh should
be documented. This is a first step of documenting them.
|
| |
|
| |
|
|
|
|
| |
as the code actually tests readability.
|
|
|
|
| |
to fail RDP security negotiation if certificate/privkey is not readable
|
|
|
|
|
|
|
|
|
|
|
|
| |
We shouldn't assume that xrdp daemon is running under root privilege.
In many cases, root privilege is not really needed for xrdp daemon.
xrdp may fail to load certificate/privkey due to lack of permissions
when running under user privilege. Checking existence of files is not
enough and xrdp should output user-friendly log in such case.
Reported by Debian user in bug 856436 [1].
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856436
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The UK/GB keyboard doesn't work properly connecting to xrdp with xorgxrdp.
It does work when connecting to xrdp with x11vnc, however.
This is because the layout is not declared in xrdp_keyboard.ini. It needs
to be called "gb" not "uk". (There are other layouts that have
km-nnnn.ini files that aren't declared in xrdp_keyboard.ini, so they might
have the same bug, but I haven't tested that. This is analagous to the
commits for the "ch" and "pl" layouts.)
Test case:
1. Use a PC with the UK/GB keyboard layout.
2. Create /etc/xrdp/startwm.sh as follows:
#!/bin/sh
export LANG=en_GB.UTF-8
export MDM_LANG=en_GB.UTF-8
export XTERM_LOCALE=en_GB.UTF-8
xterm
exit 0
3. Connect using rdesktop to localhost (from a session where the same
environment variables are defined).
4. Test layout-specific keys such as:
\ (backslash)
| (bar)
# (numbersign)
~ (asciitilde)
£ (sterling: Shift-3)
€ (EuroSign: AltGr-4)
These keys should produce the appropriate symbol but they don't. With
the change in this commit the keys produce the correct symbol.
|
|
|
|
|
|
| |
As some clinents (AFAIK Windows 10) always send domain name, the backend
module is not selected properly. This causes the default usage with
Windows 10 fails with 'xrdp_wm_log_msg: Section "XXX" not configured'.
|
| |
|
| |
|
|
|
|
|
| |
Do not expect prefix is always /usr. /usr/local is often used when users
compile xrdp manually.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
painter and librfxcodec are enabled by default. --disable-* options
disables them.
Before:
--disable-painter Use included painter library (default: yes)
--disable-rfxcodec Use included librfxcodec library (default: yes)
After:
--disable-painter Do not use included painter library (default: no)
--disable-rfxcodec Do not use included librfxcodec library (default:
no)
|
| |
|
| |
|
|
|
|
| |
via environment variable.
|