The only current interactivity detection code in pam is part of a
pam.conf -> pam.d conversion tool that won't be useful here.
The pam_motd code emits content via things like try_to_display_fd.
A message is created and then printed via pam_info.
Which is actually pam_prompt which wraps pam_vprompt
This gets the conversation function via
retval = pam_get_item (pamh, PAM_CONV, &convp);
and on that it then emits the message
retval = conv->conv (1, &pmsg, &pam_resp, conv->appdata_ptr);
Either via this PAM_CONV and then attributes of that channel (as it is
what we'd print on) OR via something like pam_get_item(pamh, PAM_TTY,
&tty); we might get access from pam_motd to something that we can work
out if it is interactive.
I'm busy with other things now (for the rest of today), but I want ton continue
tomorrow.
I want this at least to get into a clear state that is sure if:
a) this is as important as I think
b) the steps needed from here are clear
** Also affects: pam (Ubuntu)
Importance: Undecided
Status: New
** Changed in: pam (Ubuntu)
Status: New => Confirmed
** Changed in: update-motd (Ubuntu)
Status: Triaged => Confirmed
** Changed in: pam (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1893716
Title:
scripts in /etc/update-motd.d/ run even on login via non-interactive
scp and sftp sessions
Status in pam package in Ubuntu:
Confirmed
Status in update-motd package in Ubuntu:
Confirmed
Bug description:
My client has 200+ devices automatically uploading information via
sftp and scp to a server every few minutes. After a recent update, I
noticed the load on their server spiking through the roof. Upon
investigation, I discovered a horde of landscape-sysinfo and
/usr/bin/lsb_release processes running that correlated with login
session notifications in /var/log/syslog and the load spikes.
It appears that even in non-interactive sessions where this
information will never be seen, the configuration options below in
/etc/pam.d/sshd cause these items to be launched (in fact, probably
everything in /etc/update-motd.d). This only started on the system in
question after a recent set of system updates were installed.
The content of /etc/update-motd.d/* really, really, really shouldn't
be executed if the session in question is not interactive, as it
provides no value at all. Unfortunately, to disable it for these non-
interactive sessions, we also have to disable it for the interactive
ones as well where it has some value (though not enough to make
spiking the load on this server through the roof an acceptable
tradeoff).
# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
#session optional pam_motd.so motd=/run/motd.dynamic
#session optional pam_motd.so noupdate
Also, looking at the script 00-header in /etc/update-motd.d/,
/usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
does include the necessary information:
[ -r /etc/lsb-release ] && . /etc/lsb-release
if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
# Fall back to using the very slow lsb_release utility
DISTRIB_DESCRIPTION=$(lsb_release -s -d)
fi
# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1893716/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
