diff options
author | Simon Rettberg | 2022-01-20 13:33:11 +0100 |
---|---|---|
committer | Simon Rettberg | 2022-01-20 13:33:11 +0100 |
commit | 3d748ebe7d900e96670ff3d455896998dfba6191 (patch) | |
tree | e8bbaf6531897a2292da2158a46e9dce3df96baf /driver/passwd-pam.c | |
parent | Re-sync dpms settings on unblank (diff) | |
download | xscreensaver-3d748ebe7d900e96670ff3d455896998dfba6191.tar.gz xscreensaver-3d748ebe7d900e96670ff3d455896998dfba6191.tar.xz xscreensaver-3d748ebe7d900e96670ff3d455896998dfba6191.zip |
Diffstat (limited to 'driver/passwd-pam.c')
-rw-r--r-- | driver/passwd-pam.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/driver/passwd-pam.c b/driver/passwd-pam.c index d463bc2..457fed5 100644 --- a/driver/passwd-pam.c +++ b/driver/passwd-pam.c @@ -131,7 +131,7 @@ Bool pam_priv_init (int argc, char **argv, Bool verbose_p); set up an "xscreensaver" PAM service. However, if we went that route, it would have a really awful failure mode: the failure mode would be that xscreensaver was willing to *lock* the screen, but would be unwilling to - *unlock* the screen. (With the non-PAM password code, the analagous + *unlock* the screen. (With the non-PAM password code, the analogous situation -- security not being configured properly, for example do to the executable not being installed as setuid root -- the failure mode is much more palettable, in that xscreensaver will refuse to *lock* the screen, |