Bug 264361 - x11/xscreensaver: version 6.02 fails to lock the screen upon resume
Summary: x11/xscreensaver: version 6.02 fails to lock the screen upon resume
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-31 09:36 UTC by Alexey Dokuchaev
Modified: 2022-09-02 20:15 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Dokuchaev freebsd_committer freebsd_triage 2022-05-31 09:36:07 UTC
Another regression had been identified with the recently committed version 6.02: previously (on 5.44), when putting laptop to sleep which exceeds configured timeout, XScreenSaver would lock the screen upon resume, apparently detecting that the clock had advanced far enough during the sleep.  Now it no longer does this, which is annoying and insecure.  I've tried to build the very latest version 6.04 and it also failed to lock the screen for me (however, this data point is weak as I had to cut some corners during the configure stage to get it working).
Comment 1 Charlie Li freebsd_committer freebsd_triage 2022-08-31 01:19:52 UTC
When resuming, at least on my two setups with xscreensaver, it does lock since 6.03.
Comment 2 Luna Jernberg 2022-08-31 04:18:45 UTC
Have this bug too
Comment 3 Felix Palmen freebsd_committer freebsd_triage 2022-08-31 06:45:43 UTC
(In reply to Alexey Dokuchaev from comment #0)
Can you please verify whether 6.04 is still affected?

If so, as we're on the latest version now and our port only contains a trivial patch to utils/textclient.c (and one other patch only affecting one of the "hacks"), this should probably be reported upstream:
https://www.jwz.org/xscreensaver/bugs.html
Comment 4 Alexey Dokuchaev freebsd_committer freebsd_triage 2022-08-31 14:03:10 UTC
(In reply to Felix Palmen from comment #3)
> Can you please verify whether 6.04 is still affected?
Sure thing, but not until I can build it:

$ make OPTIONS_UNSET=PAM BATCH= build
...
===>  Script "configure" failed unexpectedly.
Comment 5 Felix Palmen freebsd_committer freebsd_triage 2022-08-31 15:11:28 UTC
(In reply to Alexey Dokuchaev from comment #4)
Tested all options back for 6.02, this worked back then. Currently my builder is busy, will try to reproduce this later!

Just out of curiosity, what's the usecase to disable PAM support? I was already thinking that this option could be removed...
Comment 6 Sergey V. Dyatko 2022-08-31 15:16:11 UTC
(In reply to Felix Palmen from comment #3)

Hi
6.04 doesn't work for me. After upgrade to this version I lost the ability to unlock my laptop

/var/log/messages :

Aug 31 16:39:33 laptop kernel: pid 10531 (xscreensaver-auth), jid 0, uid 1001: exited on signal 11
Aug 31 16:39:36 laptop kernel: pid 10537 (xscreensaver-auth), jid 0, uid 1001: exited on signal 11

with xscreensaver-6.02_1 I can successfully unlock it

btw, besides with resume bug 6.02 have a bug with backspace button - try to type string, then press-and-hold BS
with 6.04 it is fixed but makes work with laptop hard

so I think that v6.02 less harmful than 6.04
Maybe there are some tweaks/hacks that need to be done to get v6.04 working?
Comment 7 Felix Palmen freebsd_committer freebsd_triage 2022-08-31 15:20:11 UTC
(In reply to Sergey V. Dyatko from comment #6)
> Aug 31 16:39:36 laptop kernel: pid 10537 (xscreensaver-auth), jid 0, uid 1001:
> exited on signal 11
Is your system fully upgraded? For 13.0, you need at least -p12, for 13.1 at least -p1. There's an explicit warning about this when installing security/unix-selfauth-helper which is now a run dependency for xscreensaver with PAM enabled.

> btw, besides with resume bug 6.02 have a bug with backspace button - try to
> type string, then press-and-hold BS
> with 6.04 it is fixed but makes work with laptop hard
Sorry, I didn't understand this?

Could you please tell me whether 6.04 still doesn't lock the screen upon resume as expected?
Comment 8 commit-hook freebsd_committer freebsd_triage 2022-08-31 16:48:48 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=e4add0d91e9608ca80247f6765cc0f37b7cb68a1

commit e4add0d91e9608ca80247f6765cc0f37b7cb68a1
Author:     Felix Palmen <zirias@FreeBSD.org>
AuthorDate: 2022-08-31 16:31:55 +0000
Commit:     Felix Palmen <zirias@FreeBSD.org>
CommitDate: 2022-08-31 16:47:46 +0000

    UPDATING: Add entry for x11/xscreensaver

    Warn about crashing pam_exec.so on 13.1-RELEASE prior to -p1.

    PR:             264361
    Approved by:    tcberner (mentor)

 UPDATING | 13 +++++++++++++
 1 file changed, 13 insertions(+)
Comment 9 Sergey V. Dyatko 2022-08-31 17:14:41 UTC
(In reply to Felix Palmen from comment #7)
it is  

[tiger@laptop]:~%uname -a
FreeBSD laptop.domain 14.0-CURRENT FreeBSD 14.0-CURRENT #16 n255231-464907ce1cf9-dirty: Wed May 11 14:48:07 +03 2022     root@laptop.domain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
I do not track releases so I don't know what's newer - my system or 13.1-RELEASE-pX
Also there is no any warnings during security/unix-selfauth-helper installation. 

I think security/unix-selfauth-helper need to be modified if my case pam_exec related (${OSVERSION} check needed I suppose)

> Could you please tell me whether 6.04 still doesn't lock the screen upon resume as expected?

I don't know because my laptop was locked before suspend (via inactivity timeout) and I can't login with 6.04. It is quite enough case for me not to test suspend/resume
Comment 10 Felix Palmen freebsd_committer freebsd_triage 2022-08-31 17:26:45 UTC
(In reply to Sergey V. Dyatko from comment #9)
> Wed May 11 14:48:07 +03 2022
This is too old (by a few days btw). See original bug 263893 that's also linked in the EN.

> I do not track releases so I don't know what's newer - my system or
> 13.1-RELEASE-pX
You get a rough idea from the fix dates in the EN, plus the original PR is linked there.

> I think security/unix-selfauth-helper need to be modified if my case
> pam_exec related (${OSVERSION} check needed I suppose)
This won't happen (besides, the pam_exec fix didn't get an OSVERSION bump).
-CURRENT will break from time to time. You're not supposed to use it "in production", and if you're using it, you're supposed to keep it up to date regulary.
Comment 11 John Hein 2022-09-01 21:40:48 UTC
On 12.3-stable, 'make configure' now fails due to:

    Warning: Your system seems to have PAM, but PAM is not being used.
             That is probably not going to work out well.

This is not really a warning as configure sets 'CONF_STATUS=1' making this fatal to configure.


if test "$with_pam_req" = yes -a "$have_pam" = no ; then
  warn 'Use of PAM was requested, but it was not found.'
  CONF_STATUS=1
elif test "$have_pam" = no ; then
  if test -d /etc/pam.d -o -f /etc/pam.conf ; then
    warn  "Your system seems to have PAM, but PAM is not being used."
    warn2 "That is probably not going to work out well."
    CONF_STATUS=1
  fi
fi
Comment 12 John Hein 2022-09-01 21:45:52 UTC
(In reply to John Hein from comment #11)
I should have said that was with PAM=off (saved that way on this system which had 6.02_2 installed before the update to 6.04).

When I set PAM=on, 'make configure' works.
Comment 13 Felix Palmen freebsd_committer freebsd_triage 2022-09-02 05:43:19 UTC
So, upstream doesn't think PAM should be optional any more. And building our base WITHOUT_PAM doesn't work any more either. I will therefore remove the PAM option entirely from this port.

Still, can anybody confirm this new version *does* lock the screen after resuming?
Comment 14 Sergey V. Dyatko 2022-09-02 09:21:37 UTC
(In reply to Felix Palmen from comment #13)
i have a plan to update my 14-CURRENT today and report
Comment 15 Sergey V. Dyatko 2022-09-02 12:48:29 UTC
(In reply to Felix Palmen from comment #13)
> Still, can anybody confirm this new version *does* lock the screen after resuming?

works fine to me
Comment 16 commit-hook freebsd_committer freebsd_triage 2022-09-02 20:13:06 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=ecc6daf598b26b1b3a2e4e48b26d55c1e3636437

commit ecc6daf598b26b1b3a2e4e48b26d55c1e3636437
Author:     Felix Palmen <zirias@FreeBSD.org>
AuthorDate: 2022-09-02 06:15:24 +0000
Commit:     Felix Palmen <zirias@FreeBSD.org>
CommitDate: 2022-09-02 20:11:33 +0000

    x11/xscreensaver: Remove PAM option

    Upstream ./configure now fails with --without-pam if PAM is found on the
    build system with this message:

      Your system seems to have PAM, but PAM is not being used.
      That is probably not going to work out well.

    We have PAM in base and can't build base without it any more
    (WITHOUT_PAM is deprecated), so let's just remove that port option and
    always build xscreensaver with PAM (previously enabled by default).

    With PAM enforced, support for shadow passwords is not needed. Forcing
    it to off, we can avoid installing xscreensaver-auth suid root.

    PR:                     264361
    Approved by:            x11 (cy, manu), tcberner (mentor)
    Differential Revision:  https://reviews.freebsd.org/D36425

 x11/xscreensaver/Makefile                       | 16 +++++++---------
 x11/xscreensaver/files/patch-driver_Makefile.in | 13 ++-----------
 x11/xscreensaver/pkg-plist                      |  2 +-
 3 files changed, 10 insertions(+), 21 deletions(-)
Comment 17 Felix Palmen freebsd_committer freebsd_triage 2022-09-02 20:15:38 UTC
(In reply to Sergey V. Dyatko from comment #15)
Thank you!

With now two reports that this is solved in 6.04, I'm closing this PR.

If there's still an issue, please feel free to reopen!