We've gotten a report that tl-session is trying to look up the host "thinlinc" as part of every session startup. If there are problems with this lookup then the startup can be delayed, possibly up until the point where vsmagent gives up and considers the startup failed. We're not sure where this lookup is coming from, but the current theory is that some PAM module does this as a result of us setting PAM_RHOST to "thinlinc". We added that for a good reason though so removing is not a good idea. Perhaps using an IP address from the RFC 5737 range instead? More investigation is needed.
I've confirmed this issue on our internal ThinLinc system (4.4.0 on RHEL 6).
It's the auditing that is causing this. Backtrace: #0 getaddrinfo (name=0x60ea00 "thinlinc", service=0x0, hints=0x7fffffff5ab0, pai=0x7fffffff5ae8) at ../sysdeps/posix/getaddrinfo.c:2294 #1 0x0000003ee4606ce6 in _resolve_addr (buf=0x7fffffff7e60 "?", host=0x60ea00 "thinlinc") at audit_logging.c:65 #2 0x0000003ee4607639 in audit_log_user_message (audit_fd=7, type=2300, message=0x611420 "pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0 selected-context=unconfined_u:unconfined_r:unconfined_t:s0", hostname=0x60ea00 "thinlinc", addr=<value optimized out>, tty=0x60e9e0 "/dev/thinlinc", result=1) at audit_logging.c:263 #3 0x00007ffff5dafb27 in ?? () from /lib64/security/pam_selinux.so #4 0x00007ffff5db05a6 in pam_sm_open_session () from /lib64/security/pam_selinux.so #5 0x0000003110202cee in ?? () from /lib64/libpam.so.0 #6 0x0000003110207168 in pam_open_session () from /lib64/libpam.so.0 Will have to check the code to see if it can be avoided.
A second audit call is made during login: #0 getaddrinfo (name=0x60ea00 "thinlinc", service=0x0, hints=0x7fffffff6b80, pai=0x7fffffff6bb8) at ../sysdeps/posix/getaddrinfo.c:2294 #1 0x0000003ee4606ce6 in _resolve_addr (buf=0x7fffffff8f90 "?", host=0x60ea00 "thinlinc") at audit_logging.c:65 #2 0x0000003ee4607876 in audit_log_acct_message (audit_fd=8, type=1105, pgname=0x0, op=0x7fffffff9050 "PAM:session_open", name=0x605170 "tltest", id=4294967295, host=0x60ea00 "thinlinc", addr=0x0, tty=0x60e9e0 "/dev/thinlinc", result=1) at audit_logging.c:405 #3 0x00000031102080a0 in ?? () from /lib64/libpam.so.0 #4 0x000000311020825d in ?? () from /lib64/libpam.so.0 And a third during logout: #0 getaddrinfo (name=0x60ea00 "thinlinc", service=0x0, hints=0x7fffffff6ba0, pai=0x7fffffff6bd8) at ../sysdeps/posix/getaddrinfo.c:2294 #1 0x0000003ee4606ce6 in _resolve_addr (buf=0x7fffffff8fb0 "?", host=0x60ea00 "thinlinc") at audit_logging.c:65 #2 0x0000003ee4607876 in audit_log_acct_message (audit_fd=8, type=1106, pgname=0x0, op=0x7fffffff9070 "PAM:session_close", name=0x605170 "tltest", id=4294967295, host=0x60ea00 "thinlinc", addr=0x0, tty=0x60e9e0 "/dev/thinlinc", result=1) at audit_logging.c:405 #3 0x00000031102080a0 in ?? () from /lib64/libpam.so.0 #4 0x000000311020825d in ?? () from /lib64/libpam.so.0
These log messages are not conditional in any way. And we have to make sure RHOST is set to get the proper policy with (at least) pam_ck_connector and pam_systemd. Fortunately it only has to be non-empty and not some variation of "localhost" and "localdomain". Let's see if there is something decent that can be fed to getaddrinfo() without causing an actual lookup.
Urgh. No terrific alternatives here. a) Fake name, e.g. "thinlinc" - Causes DNS lookup, which can also result in a hit and an incorrect IP address being logged. b) Invalid name, e.g. "<thinlinc>" - No lookup, but throws an error which may be logged (disabled by default). - Might trip up other modules who also assume this is something valid c) Numeric address, e.g. "203.0.113.1" - Administrators might not know that this is a reserved address and will think they're getting weird connections. - An IPv4 address will throw an error on a IPv6 only system, and vice versa c.2) Well known numeric address, e.g. "0.0.0.0" - More obvious fake to administrators, but might be identified as invalid by PAM modules or considered equivalent to localhost. d) Nothing at all - ConsoleKit and systemd mark the session as local and the user gets a bunch of privileges it's not supposed to. Right now c) seems like the least bad alternative.
There's also: e) Set it to the client's address - This address can change on reconnect but we have no way of informing the modules of this. So logs and session information will retain the initial address. - We might fail to get the address so we still need some dummy fallback.
One more: f) Modify /etc/hosts - This file might get changed and the entry removed
We're going with option c), but an address higher up in the range to avoid confusion with any address used in documentation.
See bug 5755 for follow-up for IPv6.
(In reply to comment #9) > We're going with option c), but an address higher up in the range to avoid > confusion with any address used in documentation. Tested with ThinLinc 4.5.0post 4992 and CentOS 7: * There are no longer any DNS lookups for the 'thinlinc' hostname on login or logut. * Sessions are still listed as remote (verified using loginctl show-session)
