Update sesman to cope with separate authentication/authorization (AA) and
command processing.
Also, internally users are now tracked by UID rather thn username.
This addresses a problem found by some users using federated naming
services (e.g. Active Directory) where the same user can be referred to
in more than one way. See https://github.com/neutrinolabs/xrdp/issues/1823
The separation of AA in this way allows for multiple attempts to be made
on one connection to get a password right. This addresses MaxLoginRetry
not working (https://github.com/neutrinolabs/xrdp/issues/1739)
The TCP socket implementation of sesman has a number of limitations,
namely that it is affected by firewalls, and also that determining the
user on the other end requires a full authentication process.
The advantage of the TCP socket is that sesman and xrdp can be run on
separate machines. This is however not supported by the xorgxrdp
backend (shared memory), and is insecure, in that passwords are sent
in-the-clear, and the connection is susceptible to MitM attacks. This
architecture has been deprecated in release notes since xrdp v0.9.17,
and although it will continue to be supported in any further releases
in the x0.9.x series, it will not be supported in the next major
version.
This commit adds:
* replace multiple logging macros with LOG and LOG_DEVEL
* logging configuration for chanserv
* logging configuration for console output
* logging configuration for per file or method log level filtering for
debug builds
* file, line, and method name in log message for debug builds
As the Debian patch[1] expresses, spitting messages on the console when
a process starts in background is a bad idea. Everything should be
written to log file and daemon should start silently. This is a first
step to shut up daemons.
Got some idea from Debian Remote Maintainers and Thorsten Glaser,
thanks!
[1] 2751ad4d62/debian/patches/shutup-daemon.diff
For xrdp-sesman, don't report that the daemon is listening to a port if
it fails to attach to that port. Don't use LOG_LEVEL_ALWAYS for startup
message, it's not a critical error.