** Description changed: Debian version 3.2.6+dfsg-3 adds a new dependency, `wtmpdb`. this is listed as needed in `radlast`. This caused a component-mismatch, as `wtmpdb` is in universe and not main. in doing research for a MIR, it was found that `wtmpdb` has been orphaned in Debian without explanation. https://metadata.ftp- master.debian.org/changelogs//main/w/wtmpdb/wtmpdb_0.13.0-4_changelog the upstream github project for `wtmpdb` is maintained https://github.com/thkukuk/wtmpdb The led to more discussion and research to understand the requirement for `wtmpdb` in freeradius. `radlast` is the most dense program ever written... ``` #! /bin/sh prefix=@prefix@ localstatedir=@localstatedir@ logdir=@logdir@ exec last -f $logdir/radwtmp "$@" ``` jokes aside, `radlast` requirest `last`. The root issue is that `last`, and even deeper `wtmp` and `utmp` `glibc` implementations did not undergo the 32 bit time_t transition. as of today, any `wtmp` - implementation still uses 32bit time on a 32bit system. Within - `freeradius`, this is implemented in src/modules/rlm_unix/rlm_unix.c + implementation still uses 32bit time on a 32bit system. on biarch + systems (x86-64, s390x, ppcel64), the implementation moved to an + unsigned int, so the problem got shoved an extra 70 years down the road + (at least the seconds are uint). Within `freeradius`, this is + implemented in src/modules/rlm_unix/rlm_unix.c ln358 declares the struct utmp ut ``` VALUE_PAIR *vp; vp_cursor_t cursor; FILE *fp; struct utmp ut; time_t t; char buf[64]; char const *s; int delay = 0; int status = -1; int nas_address = 0; int framed_address = 0; ``` and then when written, fopen -> fwrite(&ut) is called ``` /* * Write a RADIUS wtmp log file. * * Try to open the file if we can't, we don't write the * wtmp file. If we can try to write. If we fail, * return RLM_MODULE_FAIL .. */ if ((fp = fopen(inst->radwtmp, "a")) != NULL) { if ((fwrite(&ut, sizeof(ut), 1, fp)) != 1) { fclose(fp); return RLM_MODULE_FAIL; } fclose(fp); } else return RLM_MODULE_FAIL; return RLM_MODULE_OK; } ``` In the end, I've ended up a little confused, as reading this I see: * radwtmp is still hitting the 2038 problem * radlast will use last from wtmpdb * wtmpdb introduces a pam module to deal with login / logout events * freeradius is writing it's _own_ wtmp log using a utmp struct, so wtmpdb isn't going to be logging those in a 64 bit way Which leads to this bug and proposal: **remove wtmpdb as a dependency of freeradius** * `wtmpdb` is not in main * `wtpmdb` is orphaned in debian currently * getting a MIR and new debian owner in time for plucky release is unlikely * as plucky is an interim release, with 9 months of support, plucky itself will not hit the 2038 issue * `utmp` itself is 32 bit, and declared to be on any biarch platform (x86-64, ppc64, s390x) * thus the approach in `freeradius` is coupled to current distro implementations of `utmp`. * changing `last` won't help with that problem * adding a new pam module and login tracking mechanism for a 2038 compliant `last` feels far outside the need and scope for this package.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2096611 Title: Revert Upstream dependency on wtmpdb last in radlast To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/2096611/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
