[Pkg-shadow-devel] Bug#764841: please use pam_exec to display "dynamic" motd

Steve Langasek vorlon at debian.org
Sun Oct 12 21:39:31 UTC 2014

On Sun, Oct 12, 2014 at 09:50:14PM +0200, Michael Biebl wrote:
> > > Please consider doing the same in openssh-server's pam configuration.
> > 
> > Doesn't the motd stuff do considerably more than just uname?  On my
> > Ubuntu system it says:
> > 
> >   Welcome to Ubuntu Utopic Unicorn (development branch) (GNU/Linux 3.16.0-17-generic x86_64)
> >   
> >    * Documentation:  https://help.ubuntu.com/
> >   
> >   485 packages can be updated.
> >   0 updates are security updates.
> >   
> >   *** System restart required ***
> > 
> > So I think I need to find a way to avoid regressing that.

> Since you still keep the pam_motd line, the worst that can happen
> afaics, is that on Ubuntu the uname information would be printed twice
> (if you don't want to have delta)
> Or what kind of regression did you have in mind?

/etc/pam.d/sshd on Ubuntu does the following:

 session    optional     pam_motd.so  motd=/run/motd.dynamic
 session    optional     pam_motd.so noupdate

Calling 'pam_exec uname' on Debian would not be a regression.  It is,
however, the wrong way to go about this.  /etc/init.d/motd's writing to
/run/motd.dynamic was itself something that Roger implemented in Debian
despite the fact that update-motd support was already present in pam_motd in
Debian, for purposes of supporting much more dynamic information than just
the uname.  I can't entirely blame him, since I didn't exactly advertise
update-motd heavily in Debian or push for it; nevertheless, I think this is
part of a very bad pattern of people implementing changes to base interfaces
in Debian without any kind of central coordination with the project (i.e.,
debian-devel).  The bugs being filed to ask maintainers to pam_exec uname
are a further example of this pattern.

> Bringing Steve into the loop here, as PAM maintainer:
> Quoting IRC:
> <vorlon> mbiebl: I believe we should use /etc/update-motd.d for this,
> yes.  In principle I think it's also fine to do this via pam_exec, but
> update-motd needs to be externalized as a script first.

> As for jessie, I don't know how much effort it would be to switch to the
> update-motd mechanism and also update the login package accordingly.

To use update-motd in Debian, there's one missing piece from Ubuntu, which
is adding /etc/update-motd.d/00-header to populate the uname information. 
In Ubuntu, this is part of the base-files package, which I think is a
reasonable place for it to live in Debian as well.

With that done, it would be fairly straightforward to have the login and ssh
packages using pam_motd in Debian for jessie.

I'll mention one caveat, which is that in some cases dynamic pam_motd
presents usability problems.  However, the problematic scripts in Ubuntu
belonged to packages such as update-notifier and
ubuntu-release-upgrader-core, which are not likely to be installed on the
kind of Debian system where one cares about console login time, so this may
be negligible.


A complete solution to this bug consists of:

 - externalizing the update-motd handling out of pam_motd to an update-motd
 - having login and ssh call pam_exec update-motd
 - calling update-motd *on boot* to pre-cache the results so that first
   login after boot isn't unnecessarily slow
 - dropping the pam_motd patches after a suitable transition

> Steve, do you think it's too late to do that for jessie? What would you
> suggest?

I don't think it's too late for jessie.  It should be discussed on
debian-devel, so that we can all get on the same page, and it needs
agreement from the relevant maintainer about who should ship
/etc/update-motd.d/00-header (whether it's base-files, or something else).

> We did mask the motd init script in systemd after we were told that the
> login package was updated to no longer require it and we weren't aware
> that there were other users of that motd.dynamic file.

I assume you were told that by Josh, who filed bug #735521 and bug #741129
without ever talking to the pam maintainer about this change.

> We can certainly revert this change again for jessie, if you think the
> uname information for ssh logins is important enough.
> That said, if this can be avoided and we find an agreeable solution for
> everyone which doesn't involved generating a motd.dynamic file, then I'd
> certainly prefer that.

I think the change in systemd absolutely should be reverted.  Regardless of
the implementation that is ultimately agreed, the systemd package has no
business overriding the initscripts package.  *If* /etc/init.d/motd is to be
dropped it should be dropped at the source, *not* by an override in systemd
that results in inconsistent boot time behavior between different init

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20141012/6e087918/attachment.sig>

More information about the Pkg-shadow-devel mailing list