Public bug reported: 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 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. ** Affects: freeradius (Ubuntu) Importance: Undecided Status: New ** 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. the upstream github project for - `wtmpdb` is maintained + 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 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; + 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; + /* + * 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; + 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 + * 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 + * 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
