- LWAVING XSCREENSAVER ON OVERNIGHT SOFTWARE
- LWAVING XSCREENSAVER ON OVERNIGHT CODE
- LWAVING XSCREENSAVER ON OVERNIGHT PASSWORD
LWAVING XSCREENSAVER ON OVERNIGHT SOFTWARE
Open Source Software Security Wiki, which is counterpart to thisĬonfused about mailing lists and their use? should be reported to its vendor as a bug. This usually indicates a programming error in the crashing program and Process 8893 (xscreensaver) crashed and dumped core. Subject: Process 8893 (xscreensaver) dumped core
Xss_authenticate (xscreensaver + 0x25c59) Pam_sm_authenticate (pam_unix.so + 0x4897) Pam_get_authtok_internal (libpam.so.0 + 0x5d26) Pam_conversation (xscreensaver + 0x262c1) Passwd_event_loop (xscreensaver + 0x24229) Update_passwd_window (xscreensaver + 0x2169d) Jun 22 14:39:22 dom0 systemd-coredump: Process 8893 (xscreensaver) of
LWAVING XSCREENSAVER ON OVERNIGHT CODE
Jun 20 21:59:10 dom0 systemd: reproduction instructions*Īctually I cannot review the code at the moment therefore I don't know if Jun 20 22:24:23 dom0 systemd-coredump: Process 50175 (xrandr) of Means to ask for their help on the UEFI update. I also thought about notifying Lenovo but don't know of an effective
I am not an X11 expert,Īnd not sure if these are related to each other. The stack trace of crashed processes are below.
Screensaver crashes with desktop unlocked. Tb3 dock + laptop display), just unplug thunderbolt cable, plug it into When connected to my 3 monitor setup (two external displays through the Xscreensaver that mitigated the crash, however, it looks like there is a The Qubes OS security team has released a patched version of The behavior in CVE-2021-34557 started after I upgraded the firmware to Undocking, sometimes I use the power port, sometimes the TB3 port. I might be wrong, this is just an observation. T480sĬould not recognize external screens through the power port, but T14Ĭan. It looks like T14 has changed the behavior of the power port. Owned a T480s which had the same two ports, and one was for power and I have a Lenovo Thinkpad T14 Gen1 Intel laptop and a Lenovo TB3 dock Nothing Ive tried has had any effect on changing the delay.
LWAVING XSCREENSAVER ON OVERNIGHT PASSWORD
Might be affecting other distros therefore posting to this list. Hello, Ive encountered my first frustration with Leap (using Xfce) after installing it on my new workstation: the intolerable 10-second delay imposed by XScreenSaver (version 5.33) after an incorrect password is entered while trying to unlock the desktop. Have reported a similar issue to the Qubes OS security team. This is a new issue which results in xscreensaver crash. And also I haveĭisabled TB3 port, instead, using USB-C port only, with the dock. My workaround is to stop using xscreensaver on my system. Original post and ii) reproduction instructions. Support status of XScreenSaver on Apple Silicon Macs and Apple M1 Processors. Xscreensaver crash that might happen on some setups. I'm aware I can try gnome-screensaver or other alternatives, but I've spent so much time on this issue that I'm compelled to learn why it's happening.Follow on Twitter for new release announcements and other news Īs the embargo period has ended, I am sharing some details about an The only hint I got from running XScreenSaver with verbose output was "non-PAM password auth." XScreenSaver is the only application I know of with this problem. Since FAIL_DELAY is set to the default of 3 seconds in my /etc/fs (which is indeed being used by su authentication) and nothing is set to 10 seconds in my ~/.xscreensaver config (which doesn't even seem to support any options regarding password delay, according to the documentation), I have no idea where this timeout is coming from, whether it be from PAM, Xfce, XScreenSaver or elsewhere. I've found nothing in YaST or the Xfce configs that appears to relevant. The only source I could find on this exact issue ( ) implicates /sbin/unix2_chkpwd, yet offers no solution. Certain online forums point to pam_faildelay.so, but 'pam-config -list-modules' claims that module isn't even available on my system. sudo authentication), yet left XScreenSaver unaffected. I suffered exactly the same situation when trying openSUSE back in 2012 on a laptop with completely different hardware, but I've never seen this when using XScreenSaver on Debian.Īdding the "nodelay" option to pam_unix.so using pam-config eliminated the password delay from elsewhere in the system (e.g. Nothing I've tried has had any effect on changing the delay. I've encountered my first frustration with Leap (using Xfce) after installing it on my new workstation: the intolerable 10-second delay imposed by XScreenSaver (version 5.33) after an incorrect password is entered while trying to unlock the desktop.
0 kommentar(er)
