Bug 178779 - Updating xscreensaver unlocks the screen
Updating xscreensaver unlocks the screen
Product: Fedora
Classification: Fedora
Component: xscreensaver (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Depends On:
  Show dependency treegraph
Reported: 2006-01-24 07:10 EST by Oskari Saarenmaa
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-29 04:25:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Example patch to treat restart process (7.79 KB, patch)
2006-01-25 01:18 EST, Mamoru TASAKA
no flags Details | Diff
Renewal patch (8.02 KB, patch)
2006-01-25 04:33 EST, Mamoru TASAKA
no flags Details | Diff
log of upgrading xscreensaver where xscreensaver-command FAILS (23.54 KB, text/plain)
2006-01-26 03:33 EST, Mamoru TASAKA
no flags Details
Again renewal patch (8.23 KB, patch)
2006-02-09 07:35 EST, Mamoru TASAKA
no flags Details | Diff

  None (edit)
Description Oskari Saarenmaa 2006-01-24 07:10:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5

Description of problem:
The postinstall script of xscreensaver sends SIGHUP to xscreensaver which causes it to restart, but it also resets the screen saver state, so a locked screen gets unlocked.  This can cause problems when doing automatic or remote updates.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. rpm -Uvh --force xscreensaver*

Actual Results:  Screensaver state is reset.

Expected Results:  Screensaver keeps running, or is reactivated after the update.

Additional info:

xscreensaver state can be checked at least with the -cycle argument to xscreensaver-command, so replacing the postinstall script with something like this might work:

pids=`/sbin/pidof xscreensaver`
if [ -n "$pids" ]; then
  if xscreensaver-command -cycle >/dev/null 2>&1; then
  echo "sending SIGHUP to running xscreensaver ($pids)..." >&2
  kill -HUP $pids
  if test "x$reactivate" = "xyes"; then
    xscreensaver-command -activate 
Comment 1 Mamoru TASAKA 2006-01-24 13:41:22 EST
This script is perhaps more useful.

pids=`/sbin/pidof xscreensaver`
if [ -n "$pids" ]; then
    lock_status=`xscreensaver-command -time | grep -q locked ; echo $?`
    noblank_status=`xscreensaver-command -time | grep -q non-blanked ; echo $?`
    echo "sending SIGHUP to running xscreensaver ($pids)..." >&2
    kill -HUP $pids
    if [ $lock_status = 0 ] ; then
        sleep 1 ; xscreensaver-command -lock
    elif [ $noblank_status = 1 ] ; then
        sleep 1 ; xscreensaver-command -activate

Sleeping about 1 or so second is necessary; otherwise "sometimes"
xscreensaver-command fails with leaving a message like

xscreensaver-command: no screensaver is running on display :0.0

which means that xscreensaver-command failed to find the running 
Comment 2 Ray Strode [halfline] 2006-01-24 14:31:33 EST
those are okay work arounds, but the right fix is probably to make xscreensaver
not kill locked sessions when it gets a hangup signal.
Comment 3 Jamie Zawinski 2006-01-24 14:53:09 EST
Perhaps; but there's no *security* reason for it to ignore -HUP, because if you can send -HUP you can also 
send -9.  So I think either way of fixing it are equivalent.
Comment 4 Ray Strode [halfline] 2006-01-24 15:09:27 EST

So the scenario is a person starts a yum update, locks their screen and goes
home for the day.  Later that night someone else in the room notices the
screensaver dies and then has access to the machine for the night.

The patch in comment 1 tries to address the above scenario by restarting
xscreensaver if it dies.  There are two problems with it

1) xscreensaver is a session daemon, so starting it from %post in the spec file
will just try to run xscreensaver as root with no display, etc...

2) even if it did work, it gives am (albeit small) window for the person who
notices the screensaver die to type pkill xscreensaver at an open terminal or
something and then gain access to the computer.  Probably not a big threat, but
there's definitely a race.
Comment 5 Jamie Zawinski 2006-01-24 15:23:28 EST
No, doing "xscreensaver-command -restart" will not launch xscreensaver as root, it will re-launch it as 
the user who initially launched it.  "xscreensaver-command" does not do the exec(), it just sends a 
message to the existing "xscreensaver" process, which does the exec() in the same context it was 
initially started in.  The -restart message does the right thing even if sent by root.  

And "xscreensaver-command -restart" and "kill -HUP" do exactly the same thing, except that the 
former requires a connection to the logged-in user's $DISPLAY while the latter requires only that you be 
able to signal that users' processes.

Simply not re-launching when the screen is locked is probably a good idea, and what I was trying to say 
is that I don't think it makes any difference whether that behavior is in the %post script or hardcoded 
into the daemon itself: they will be functionally equivalent.

However, it's not clear to me that *not* restarting it is safe either.  If /usr/bin/xscreensaver is running, 
and yum has overwritten the file, what happens when it swaps?  Will it get an illegal instruction?  I know 
I've had trouble in the past with other daemons dying as a result of yum having upgraded the rug out 
from under them.
Comment 6 Oskari Saarenmaa 2006-01-24 15:36:31 EST
I think reactivating should be handled by xscreensaver instead of the post
installation script as the script won't be able to figure out what $DISPLAY the
screensavers were running on, although it appears to default to :0.0 which is
probably safe in most cases.

Or maybe xscreensaver could just ignore the restart request until it has been
Comment 7 Mamoru TASAKA 2006-01-25 01:18:19 EST
Created attachment 123652 [details]
Example patch to treat restart process

In fact, even if I wait for 1 or so seconds to invoke xscreensaver-command
after xscreensaver is restarted by SIGHUP signal (see my comment 1), screen
often fails to blank or lock when system is busy.

As Oskari commented in comment 6, the solution I can think for now is to give
xscreensaver command the state before SIGHUP command was sent by creating some
extra argument.

I attached a sample patch to follow this behaviour. It seems to work for me.
This patch does:
1. Before restarting, check if screen is locked or blanked.
2. Create some extra arguments then restart.
3. Throw away the added arguments
Comment 8 Mamoru TASAKA 2006-01-25 04:33:34 EST
Created attachment 123658 [details]
Renewal patch

Renewal patch with some modification of memory treatment about malloc and so
Comment 9 Ray Strode [halfline] 2006-01-25 10:42:19 EST
Hi guys,

What i'm wondering is how root has access to the user's display?  Are you guys
setting $XAUTHORITY to the user's xauth file before starting the upgrade?  maybe
you guys are using sudo?  It seems like it would break in general because
displays require authentication that you don't get automatically as root.
Comment 10 Mamoru TASAKA 2006-01-25 12:25:58 EST
Umm.. when I get login to root by "su -", root's $XAUTHORITY points to root
xauth file (as usual, not the original user's file), $DISPLAY is :0.0, and
executing xscreensaver-command by root blanks or lockes user's display.

Ray, your question means that "why xscreensaver daemon accepts the requirement
to lock or blank screen from root by xscreensaver-command"?

I am not familiar with X authentication framework. As far as I know,
xscreensaver-command simply sends a client message to the display governed by
xscreensaver daemon by XSendEvent ( as the comment 5 by Jamie )

   if (! XSendEvent (dpy, window, False, 0L, &event)) 

(in send_xscreensaver_command() in remote.c), and this client message (event) is
interpreted by xscreensaver daemon.  

Even if I login the other user by "su - (non-root user)", the user can blank or
lock xscreensaver screen (for me).
Comment 11 Mamoru TASAKA 2006-01-26 03:33:51 EST
Created attachment 123709 [details]
log of upgrading xscreensaver where xscreensaver-command FAILS

Okay. I might have understood what Ray is in question. When $XAUTHORITY is not
set, root cannot lock or blank screen by xscreensaver-command.

I usually login with GUI and when I need to upgrade xscreensaver, I launch some

GUI terminal, switch to root in the terminal (then $XAUTHORITY is set to
/root/.xauth...) , then execute 'rpm -F (rpms)' or 'yum -y upgrade (packages)'.
In this case, invoking xscreensaver-command in postinstall process suceeds.

There can be the case where root user trying to  upgrading package doesn't have
$XAUTHORITY value (upgrading automatically by yum is this case?) , where
xscreensaver is running on GUI, which is invoked by normal user. 

I made a experiment:
1. Launch xscreensaver by normal user in GUI.
2. Create xscreensaver rpm with postinstall script like my comment 1.
3. Lock GUI.
4. Switch to CUI,  and try to upgrade xscreensaver rpm
5. Quickly back to GUI (screen is back at this point), and see screen is locked
again by postinstall script

Result: xscreensaver-command fails (see the log attached).

So, as Ray has questioned about this, locking screen again by postinstall
script like my comment 1 or Oskari firstly proposed is not proper: locking or
blanking screen again must be handled by xscreensaver itself.

Even this case, my patch at my comment 8 should suceed: With my patch,
xscreensaver daemon examines the status of screen before restart, and give the
status by adding  some extra argument to new xscreensaver daemon (invoked by
Comment 12 Mamoru TASAKA 2006-01-26 03:38:40 EST
( Oh, I missed typing some information. In my experiment in comment 11, screen
is  unblanked and don't lock again.)
Comment 13 Mamoru TASAKA 2006-02-09 07:35:40 EST
Created attachment 124433 [details]
Again renewal patch

Again renewal patch.
In the previous patch (id=123658), the treatment of lock or blank mode in
second or later cycle was wrong. Fixed it.
Comment 14 Mamoru TASAKA 2006-09-29 04:25:29 EDT
Rawhide xscreensaver(-5.01-2) changed so that
* xscreensaver won't restart when upgrading.
* so manual restart is required when necessary.

Note You need to log in before you can comment on or make changes to this bug.