Possible a bug in Xscreensaver on FreeBSD 13.1?

Manuel L · Jun 12, 2022

Hi hello dear people, i just have a question may be a possible bug in Xscreensaver using FreeBSD 13.1 ? (I am using lastes version of GhostBSD which is based on FreeBSD 13.1, but I am not asking for support just wondering something, may be possible a bug). I usually use Xscreensaver to make some videos (just recording the scenes as backgrounds) but at this time I have a little problem that the preview button seems not to be working and I just get an error message (may be I will add some screenshots or the error message later). Should I report the bug here or may be on the freshports webpage ?

George · Jun 12, 2022

There are four bug reports on xscreensaver already, but you might want to add yours as well:

Bug List

bugs.freebsd.org

And yes, please share the content of the error message.

Geezer · Jun 13, 2022

Manuel L said:
Hi hello dear people, ...

Oh yes, that is very good.

Back to your subject, I am afraid that the version in the ports is 5.44 (as opposed to 6.04, the latest), and according to the splash screen is "VERY OLD!"

zirias@ · Jun 13, 2022

Geezer said:
I am afraid that the version in the ports is 5.44 (as opposed to 6.04, the latest)

The version in ports is 6.02. (since May 2nd, yes this took ridiculously long mostly because of a problem with PAM, and it isn't in quarterly packages yet)

I have a review for ~~6.03~~ 6.04 open ~~(and now that 6.04 is there, might update it even before being committed)~~.

Problem is that it depends on a new tool I added (also in the review stack), because xscreensaver 6.03 removed all code for calling an external suid-root helper for PAM, which was finally the workaround for 6.02. This new tool only works with a bugfix* for pam_exec(8) that was committed to CURRENT, but is still awaiting MFC and then an EN to get it on the release (12.3, 13.1) versions...

---
*) covacat identified the problem, btw ?:

su segfaults when adding some custom pam_exec to the auth stack

Asking here before opening a PR, because I'm not sure whether I might be doing something wrong... I'm trying to allow "self-authentication" against the local passwd database without requiring root privileges. The typical usecase for this is screen lockers, and the typical workaround for them is...

forums.freebsd.org

omarsidd · Jan 10, 2023

zirias@ said:
The version in ports is 6.02. (since May 2nd, yes this took ridiculously long mostly because of a problem with PAM, and it isn't in quarterly packages yet)

I have a review for ~~6.03~~ 6.04 open ~~(and now that 6.04 is there, might update it even before being committed)~~.

Problem is that it depends on a new tool I added (also in the review stack), because xscreensaver 6.03 removed all code for calling an external suid-root helper for PAM, which was finally the workaround for 6.02. This new tool only works with a bugfix* for pam_exec(8) that was committed to CURRENT, but is still awaiting MFC and then an EN to get it on the release (12.3, 13.1) versions...

---
*) covacat identified the problem, btw ?:

su segfaults when adding some custom pam_exec to the auth stack

Asking here before opening a PR, because I'm not sure whether I might be doing something wrong... I'm trying to allow "self-authentication" against the local passwd database without requiring root privileges. The typical usecase for this is screen lockers, and the typical workaround for them is...

forums.freebsd.org

This issue still exists in current port (6.06) and current 13.1 releng (13.1-RELEASE-p5). Bug 268033 describes it but is currently closed without a fix. I added a comment with details there also.

More broadly, as a community we aren't well-served by having fresher but unstable or broken ports in the general ports tree.

I don't know about others, but I'd much (much much much) rather have the version self-described as "VERY OLD!" than a work-in-progress that's broken for months on the current release... Or there should be a process for maintainers to roll such ports back to a functional version. Or at least mark it as broken?!
But "doesn't work on the recommended actively maintained current branch and users have to individually figure that out" shouldn't be considered an option.

zirias@ · Jan 10, 2023

omarsidd the original stacktrace posted there clearly shows it's the pam_exec.so issue that was fixed in 13.1-RELEASE-p1: https://www.freebsd.org/security/advisories/FreeBSD-EN-22:19.pam_exec.asc

Your stacktrace doesn't show any context, except it's again a call to strlen() that bombs.

Either you somehow managed to still have a pam_exec.so installed without this fix: https://cgit.freebsd.org/src/commit/?h=releng/13.1&id=26db194f3db1238b9339bde23a82def8cfee10b1

Or you have discovered some completely different issue with PAM. If you're using the standard local user database (/etc/passwd and friends, and pam_unix.so), this seems pretty unlikely, because this works for lots of other users. But then, to really get an idea what's happening, a stacktrace with more information would be needed.

omarsidd said:
More broadly, as a community we aren't well-served by having fresher but unstable or broken ports in the general ports tree.

The port is extensively tested and working fine. All that was found was a bug in FreeBSD base (see above) that was fixed. I now even checked the source of xscreensaver-auth, it only contains two calls to strlen() and both are guaranteed to get a valid pointer. So, whatever causes your crash, it is not xscreensaver (the port) itself.