Hi Roman and Ludo,
It seems that xscreensaver-auth needs to be setuid instead of the main
xscreensaver binary. The screen-locker-service in xorg.scm sets the
provided package setuid and sets the required pam configuration for the
provided package. The problem is that the pam configuration needs to be set
for xscreensaver (/etc/pam.d/xscreensaver) and setuid needs to be set for
xscreensaver-auth.
Interestingly when I setuid xscreensaver-auth manually I run into the
following when unlocking:
Aug 10 13:35:02 localhost unix_chkpwd[2197]: check pass; user unknown
Aug 10 13:35:02 localhost unix_chkpwd[2197]: password check failed for user
(rhuijzer)
Aug 10 13:35:02 localhost xscreensaver-auth: pam_unix(xscreensaver:auth):
authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost=
user=rhuijzer
But this might be fixed in time by [RFC PATCH] gnu: linux-pam: Change path
I don't know how to fix this elegantly, maybe create a dedicated service
for xscreensaver instead of the standard screen-locker-service?
Thanks,
Op wo 10 aug. 2022 om 09:14 schreef Roman Scherer <
roman.scherer@burningswell.com>:
Toggle quote (94 lines)
>
> Hi Ludo and Rick,
>
> sorry for the trouble. I'm running xscreensaver on a foreign distro and
> did not notice this. Probably because somehow my screen wasn't locked,
> but still showing random screensavers.
>
> However, now that I tried the `xscreensaver-command -lock` command I see
> a dialog with a "Password initialization failed" message.
>
> The xscreensave logs also show this:
>
> xscreensaver-auth: 06:45:55: OOM: /proc/99677/oom_score_adj: Permission
> denied
> xscreensaver-auth: 06:45:55: To prevent the kernel from randomly
> unlocking
> xscreensaver-auth: 06:45:55: your screen via the out-of-memory killer,
> xscreensaver-auth: 06:45:55: "xscreensaver-auth" must be setuid root.
> xscreensaver-auth: 06:46:06: PAM: warning: /etc/pam.d/xscreensaver does
> not exist.
> xscreensaver-auth: 06:46:06: PAM: password authentication is unlikely to
> work.
> xscreensaver-auth: 06:46:15: PAM: warning: /etc/pam.d/xscreensaver does
> not exist.
> xscreensaver-auth: 06:46:15: PAM: password authentication is unlikely to
> work.
>
> When the dialog popped up, I had to switch to a terminal and kill
> xscreensaver to be able to access my desktop again.
>
> Should we revert it, until we figured out what's necesarry to get this
> working again?
>
> r0man
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
> > Hi Rick,
> >
> > Rick Huijzer <ikbenrickhuyzer@gmail.com> skribis:
> >
> >> The latest xscreensaver patch <https://issues.guix.gnu.org/56597>
> rendered
> >> xscreensaver unusable on my systems. When I try to unlock my screen I am
> >> greeted with the message 'xscreensaver: don't login as root', even
> though I
> >> don't invoke it as root.
> >>
> >>
> >> $xscreensaver-command -lock
> >> Aug 9 08:45:22 localhost shepherd[1]: [slim] xscreensaver-gfx:
> 08:45:22:
> >> 1: running as root: not launching hacks.
> >> Aug 9 09:10:29 localhost shepherd[1]: [slim] xscreensaver-command:
> locking
> >> Aug 9 09:10:32 localhost shepherd[1]: [slim] xscreensaver-gfx:
> 09:10:32:
> >> 0: running as root: not launching hacks.
> >>
> >> When I remove the
> >> (screen-locker-service xscreensaver)
> >> I run into all kinds of set-uid problems.
> >
> > Sorry about that, I built it during review but did not actually run it.
> >
> > One effect of ‘screen-locker-service’ is to make the program setuid-root
> > so that it can authenticate users. It would seem that something changed
> > in xscreensaver in that area; quoth ‘driver/subprocs.c’:
> >
> > if (getuid() == (uid_t) 0 || geteuid() == (uid_t) 0)
> > /* Prior to XScreenSaver 6, if running as root, we would change
> the
> > effective uid to the user "nobody" or "daemon" or "noaccess",
> > but even that was just encouraging bad behavior. Don't log in
> > as root. */
> > {
> > fprintf (stderr, "%s: %d: running as root: not launching
> hacks.\n",
> > blurb(), ssi->number);
> > screenhack_obituary (ssi, "", "XScreenSaver: Don't log in as
> root.");
> > goto DONE;
> > }
> >
> > OTOH the ‘disavow_privileges’ function is supposed to drop root
> > privileges early on.
> >
> > So I’m not sure how it’s supposed to be run. R0man, ideas?
> >
> > Thanks,
> > Ludo’.
>
