Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Sam Hartman]

I've read the wiki page.  I'm fine with the proposed approach.  I note
that by including pam_lastlog2.so in a pam-auth-update configuration,
other services (gdm, for example) will include lastlog info.

The fact that gdm and other display managers do not include
pam_lastlog.so suggests that it's usage is not all that important.

If pam_lastlog2 is also a session module,  I recommend it only be used
for interactive sessions
To do this include the following in the pam-auth-update config:

Session-Interactive-Only: yes




signature.asc
Description: PGP signature

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Sven Joachim]

On 2024-04-08 15:46 +0200, Chris Hofstaedtler wrote:

> To clarify, because I think there is still some ongoing
> confusion regarding binary files and binary packages, here a table:
>
> Debian package name  | (primary) file(s)
> 
> liblastlog2-0| /usr/lib/.../liblastlog2.so.*
> libpam-lastlog2  | /usr/lib/.../pam_lastlog2.so
> lastlog2 | /usr/bin/lastlog2 (probably + symlink "last")

I think you mean "lastlog" rather than "last" here, the latter displays
wtmp entries.

> I think my biggest open questions for the packaging itself are:
>
> * Which package will pull in lastlog2 and libpam-lastlog2, for
>   for upgrades from bookworm?

If lastlog2 takes over the lastlog binary, the logical package seems to
be login which is currently shipping it.  The only question is if it
that should be done via Depends or Recommends, I would prefer the latter
to avoid pulling in libsqlite3 in every container/chroot.

> * Should /usr/bin/lastlog2 be in a separate lastlog2 package or not?

It could be in its own package or in util-linux-extra, I have no
particular preference.

> * Should lastlog2 Depend: libpam-lastlog2? Vice versa? Only
>   Recommends?

I think lastlog2 needs to depend on libpam-lastlog2, because it is not
useful otherwise.  There may be a few cornercases such as having
installed lastlog2 and login or sshd from different architectures, but
then the local admin should know what they are doing and install
libpam-lastlog2 for all architectures.  There does not seem to be any
particular reason why libpam-lastlog2 should recommend lastlog2.

Cheers,
   Sven

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

* Iker Pedrosa  [240408 09:19]:
> > >- Did you consider using a systemd service to upgrade from lastlog to
> > >lastlog2 data?
> >
> > No, I did not consider this, as I wasn't aware of any
> > implementations for this. Does u-l upstream ship such a service?
> >
> 
> Yes,
> https://github.com/util-linux/util-linux/blob/master/misc-utils/lastlog2-import.service.in

Thanks!

ISTM we could do this in the postinst script instead, to avoid
installing single-use services on all systems.

Chris

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

* Colin Watson  [240408 10:55]:
> On Mon, Apr 08, 2024 at 09:19:09AM +0200, Iker Pedrosa wrote:
> > On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler  wrote:
> > > util-linux upstream provides three binary objects to be built:
> > > - liblastlog2.so
> > > - pam_lastlog2.so
> > > - lastlog2 (program)
> > >
> > > Debian's PAM policy says to put PAM modules into their own package,
> > > thus libpam-lastlog2. liblastlog2.so would go into the
> > >
> > liblastlog2(-0) package. The lastlog2 program either into its own
> > > lastlog2 package, or elsewhere.
> > >
> > 
> > Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all
> > pam modules start with the prefix pam_*.
> 
> The file names do, but the package names almost always start with
> "libpam-".  (Also, Debian package names may not contain "_".)
> 
>   $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
> ^libpam-
>   68
>   $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
> ^pam-
>   1
> 
> And the Debian PAM mini-policy says:
> 
>   1) Packages should use the naming scheme of `libpam-' (eg.
>   libpam-ldap).

Indeed. To clarify, because I think there is still some ongoing
confusion regarding binary files and binary packages, here a table:

Debian package name  | (primary) file(s)

liblastlog2-0| /usr/lib/.../liblastlog2.so.*
libpam-lastlog2  | /usr/lib/.../pam_lastlog2.so
lastlog2 | /usr/bin/lastlog2 (probably + symlink "last")

I think my biggest open questions for the packaging itself are:

* Which package will pull in lastlog2 and libpam-lastlog2, for
  for upgrades from bookworm?

* Should /usr/bin/lastlog2 be in a separate lastlog2 package or not?

* Should lastlog2 Depend: libpam-lastlog2? Vice versa? Only
  Recommends?

Chris

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Colin Watson]

On Mon, Apr 08, 2024 at 09:19:09AM +0200, Iker Pedrosa wrote:
> On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler  wrote:
> > util-linux upstream provides three binary objects to be built:
> > - liblastlog2.so
> > - pam_lastlog2.so
> > - lastlog2 (program)
> >
> > Debian's PAM policy says to put PAM modules into their own package,
> > thus libpam-lastlog2. liblastlog2.so would go into the
> >
> liblastlog2(-0) package. The lastlog2 program either into its own
> > lastlog2 package, or elsewhere.
> >
> 
> Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all
> pam modules start with the prefix pam_*.

The file names do, but the package names almost always start with
"libpam-".  (Also, Debian package names may not contain "_".)

  $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
^libpam-
  68
  $ apt-file search security/pam_ | grep -v libpam-modules | grep --count ^pam-
  1

And the Debian PAM mini-policy says:

  1) Packages should use the naming scheme of `libpam-' (eg.
  libpam-ldap).

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Iker Pedrosa]

Hi,

On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler  wrote:

> Hi,
>
> * Iker Pedrosa  [240403 09:43]:
> > Hi Chris,
> >
> > I have some questions regarding your proposal:
> >
> >- What is the difference between liblastlog2 and libpam-lastlog2
> >binaries? Upstream util-linux only provides one binary (lastlog2) so
> this
> >confuses me.
>
> util-linux upstream provides three binary objects to be built:
> - liblastlog2.so
> - pam_lastlog2.so
> - lastlog2 (program)
>
> Debian's PAM policy says to put PAM modules into their own package,
> thus libpam-lastlog2. liblastlog2.so would go into the
>
liblastlog2(-0) package. The lastlog2 program either into its own
> lastlog2 package, or elsewhere.
>

Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all
pam modules start with the prefix pam_*.

Everything else sounds good.


>
> >- Did you consider using a systemd service to upgrade from lastlog to
> >lastlog2 data?
>
> No, I did not consider this, as I wasn't aware of any
> implementations for this. Does u-l upstream ship such a service?
>

Yes,
https://github.com/util-linux/util-linux/blob/master/misc-utils/lastlog2-import.service.in


>
> > This way when the distribution is updated to the next
> >version you can also remove the lastlog binary and all its
> dependencies. In
> >addition, you can use "--disable-lastlog" in shadow to stop building
> this
> >binary.
>
> Chris
>
>

-- 

Iker Pedrosa

Senior Software Engineer, Identity Management team

Red Hat 

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi,

* Iker Pedrosa  [240403 09:43]:
> Hi Chris,
> 
> I have some questions regarding your proposal:
> 
>- What is the difference between liblastlog2 and libpam-lastlog2
>binaries? Upstream util-linux only provides one binary (lastlog2) so this
>confuses me.

util-linux upstream provides three binary objects to be built:
- liblastlog2.so
- pam_lastlog2.so
- lastlog2 (program)

Debian's PAM policy says to put PAM modules into their own package,
thus libpam-lastlog2. liblastlog2.so would go into the
liblastlog2(-0) package. The lastlog2 program either into its own
lastlog2 package, or elsewhere.

>- Did you consider using a systemd service to upgrade from lastlog to
>lastlog2 data?

No, I did not consider this, as I wasn't aware of any
implementations for this. Does u-l upstream ship such a service?

> This way when the distribution is updated to the next
>version you can also remove the lastlog binary and all its dependencies. In
>addition, you can use "--disable-lastlog" in shadow to stop building this
>binary.

Chris

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Iker Pedrosa]

Hi Chris,

I have some questions regarding your proposal:

   - What is the difference between liblastlog2 and libpam-lastlog2
   binaries? Upstream util-linux only provides one binary (lastlog2) so this
   confuses me.
   - Did you consider using a systemd service to upgrade from lastlog to
   lastlog2 data? This way when the distribution is updated to the next
   version you can also remove the lastlog binary and all its dependencies. In
   addition, you can use "--disable-lastlog" in shadow to stop building this
   binary.


On Tue, Apr 2, 2024 at 4:50 PM Chris Hofstaedtler  wrote:

> Hi everyone,
>
> * Chris Hofstaedtler  [240330 01:42]:
> > > So, after some of the current fog clears, src:util-linux could
> [..]
> > >
> > > Does this seem right?
>
> I've put everything I know of into this wiki page:
>
>https://wiki.debian.org/PamLastlog2
>
> I would invite you all to review / edit it as you see fit, and/or
> start a discussion in this bug.
>
> After we have something that we can agree on, I'd send it as a
> proposed plan to debian-devel.
>
> Please also let me know if you think it's fine as is.
>
> Thanks!
> Chris
>
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel
>
>

-- 

Iker Pedrosa

Senior Software Engineer, Identity Management team

Red Hat 

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

Hi everyone,

* Chris Hofstaedtler  [240330 01:42]:
> > So, after some of the current fog clears, src:util-linux could
[..]
> > 
> > Does this seem right?

I've put everything I know of into this wiki page:

   https://wiki.debian.org/PamLastlog2

I would invite you all to review / edit it as you see fit, and/or
start a discussion in this bug.

After we have something that we can agree on, I'd send it as a
proposed plan to debian-devel.

Please also let me know if you think it's fine as is.

Thanks!
Chris

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Serge E. Hallyn]

On Sat, Mar 30, 2024 at 01:41:40AM +0100, Chris Hofstaedtler wrote:
> Hi OpenSSH, shadow Maintainers,
> 
> On Sat, Mar 30, 2024 at 01:32:08AM +0100, Chris Hofstaedtler wrote:
> > On Fri, Mar 29, 2024 at 06:02:39PM +0100, Sven Joachim wrote:
> > > It seems desirable to ship liblastlog2 in trixie, considering that the
> > > /var/log/lastlog file is not Y2038-safe and pam in unstable has already
> > > dropped pam_lastlog.so, meaning that non-ssh logins are no longer
> > > recorded in /var/log/lastlog.
> > 
> [..]
> > At the same time, all traditional writing to /var/log/lastlog should
> > stop.
> > 
> > So, after some of the current fog clears, src:util-linux could
> > introduce new binary packages (at least libpam-lastlog2), but
> > src:pam would need to add it to the common-* config files.
> > 
> > Does this seem right?
> 
> Answering my own question, not quite.
> 
> Apparently, traditionally we have:
> 
> * sshd writes to /var/log/lastlog by itself.
> * login has pam_lastlog.so in its PAM snippet. 
> 
> Both of these would need to be replaced by pam_lastlog2.so. I don't
> really know what the other distros are doing right now, and/or if
> we should align on this.
> 
> So we could either put pam_lastlog2.so into a common-* file from
> src:pam, or openssh and shadow should switch their setup.
> 
> What do we all think about that?

Hi Chris,

It doesn't look like upstream shadow is specifying pam_lastlog.so,
but debian login does.

Putting pam_lastlog2.so into a common-* from src:pam sounds like a good
solution.

thanks,
-serge