[Pkg-shadow-devel] Bug#488420: login: no proper way for a CDD to disable failed logins recording

[intrigeri at boum.org]

Package: login
Version: 1:4.1.1-1
Severity: wishlist

Hello,

In short, my proposal is to modify the login postinst script to create
/var/log/faillog only on initial install (performed by d-i and
debootstrap), and not on subsequent upgrades. Please read on to
understand why this solution, or any other one, is needed.

,----
| Context
`----

There is some work being done to give the Debian system administrator
the means to implement site-logging policies. Once the preliminary
bricks have entered Debian, the result of this work will be proposed
for inclusion as one or several meta-package(s) / CDD(s) allowing easy
privacy-enforcing system configuration. Hence the need to make it
possible to automatically configure such aspects of a system « the
Debian way », rather than by hand-editing a pile of conffiles.

Today’s focus is to allow a Debian system administrator to disable
login records book-keeping.

This bug report is a small step on the way to make this possible
(another step being the related Debian bug #488376... more to come).

,----
| Current /var/log/faillog behavior
`----

Amongst others, the /var/log/faillog world-readable file gathers
privacy-sensitive data (every user’s time and date of last failed
login). Not too sensitive, one may think, but objective truth is hard
to tell in this area : depending on the context, it may or not be
dangerous to expose some given personal data piece to any user of
the system.

AFAIK, only the login binary updates /var/log/faillog, if, and only
if :
  - this file already exists on the system
AND
  - FAILLOG_ENAB is enabled in /etc/login.defs

Nota bene : the current login’s postinst script unconditionally
creates /var/log/faillog, be it on initial install or on upgrade.

,----
| How to allow a CDD to disable faillog ?
`----

Alas, the few trivial solutions I could think of to allow a CDD to
disable /var/log/faillog book-keeping all fail :
(1) Disabling FAILLOG_ENAB /etc/login.defs does work, but IIRC the
    Debian policy forbids a package to modify another package’s
    conffile ;
(2) Deleting /var/log/faillog may at first seem to be a suitable
    solution for a CDD ; but it actually only works until the next
    login package upgrade, since this package’s postinst script
    unconditionally creates /var/log/faillog.
(3) Using dpkg-divert in the CDD to replace login’s login.defs by
    a custom one : seems a bit ugly/risky to me to divert the conffile
    of an essential package, what do you - login maintainers - think
    of this ?

Something has then to be changed somewhere... and that’s why I’m now
annoying login maintainers ;)

The solutions I could think of are :
(A) To make (1) feasible the Debian way, add a very-low-priority
    debconf question in the login package to toggle FAILLOG_ENAB
    value, so that a given CDD can use preseeding to disable it : this
    is the nicest solution I can think of, but I guess it’s not
    possible for a package in Essential, such as login, to use
    debconf, is it ?
(B) To make (2) work permanently, modify the login postinst script to
    create /var/log/faillog only on initial install (performed by
    d-i/debootstrap), and not on subsequent upgrades. This way, a CDD
    could delete this file once for all on install, and re-create it
    on removal, which :
      - is permitted since /var/log/faillog does not belong to any
        package ;
      - should not break anything : this file is only created by login
        postinst, and AFAIK its removal affects nothing else than the
        login binary − in a known and innocuous way.
    This solution was proposed by Santiago Vila for a similar bug
    (#488376) I submitted against base-files.

Any opinions, other ideas ?

If (A) is not doable, as I guess, (B) seems a nice one to me.
Would you accept a patch implementing it ?

Anyway, I’m conscious this is probably too late to implement such
a change in time for Lenny : despite it being small and not really
risky, it does not really deserve a base-system freeze exception, does
it ?

Bye, thanks to have read entirely,
--
  intrigeri <intrigeri at boum.org>