That way they will still get waitpid'd on and won't stay zombies.

Main changes:

- No longer support the case of sigprocmask failing. The new code will in that
  case have a race that can cause xsecurelock to hang; in the old code a similar
  (preexisting) race could cause other processes to get killed.
- Use only one sigprocmask call to retrieve and set the new mask.
- Do the sigprocmask calls outside the loop, not inside (fixes a race that
  appears to have caused hangs for me; repro: just hold escape).

Use criticial section in WaitPgrp.

Use explicit_bzero for password data.

This may fix some cases of old screen content appearing after resume from
suspend. Cannot reproduce these issues here though.

The C standard does not guarantee that memset won't be optimized away by
a compiler, which means that memset for password data is not safe.

Also clear password data in signal handler for SIGTERM, otherwise it
could happen that password data is left in memory that way.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

A signal race exists in WaitPgrp that could result in a kill
initiated by xsecurelock against a process that does not belong to it.

This race can happen if waitpid has been called for a child that has
already been terminated and SIGTERM is received before the pid has been
reset to 0.

In that case SIGTERM will call kill for a pid that has been already
released to the operating system and could thus have been assigned to a
new process again.

To prevent this, the criticial section blocks SIGTERM and also SIGCHLD
if WaitPgrp is supposed to block until a child status changes. If the
function is supposed to block, sigsuspend() restores SIGCHLD and SIGTERM
again and waits until a signal is delivered. These signals are blocked
and unblocked for each iteration of the loop. This is required to
actually get interrupted/killed by a SIGTERM in non-blocking mode.

If no critical section could be installed due to failure in calling
sigprocmask the old behaviour is kept.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

Having a conditional loop without breaks or returns is a better
foundation to implement a criticial section without duplicating
cleanups throughout the code.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

Centralized pid handling into WaitPgrp.

To be able to create a critical section in WaitPgrp to protect
against signal races the pid handling has been moved into
WaitPgrp.

If a child process dies, its pid is set to 0 directly in WaitPgrp
which means that a pointer has to be supplied when calling the function.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

Now disabling do_wakeup only if a key was handled externally.

Example:

XSECURELOCK_KEY_XF86AudioPause_COMMAND='playerctl --all pause'

to control media players using https://github.com/acrisci/playerctl.

Fixes #37.

Sorry for having been inconsistent before.

Show auth in a box on top of the saver

The old variable still works for compatibility if the new one isn't set.

Fixes #21.

It's then always shown on the screen with the mouse pointer.

Also added a macro SHOW_CURSOR_DURING_AUTH to actually show the pointer
- this is rather useless at the moment as auth helpers cannot receive
mouse events yet anyway. Still a nice proof of concept.

Add a feature to show cursor while auth is active (even though nothing actually receives mouse events yet).

Not in use yet, though, and there's no way for an auth helper to receive
clicks yet anyway.

This was enabled by Soumya's previous changes. Thanks!

I'd now really like to see an alternate auth helper that uses a toolkit
in single-window mode (following the monitor the mouse is on)... as
otherwise single-window auth is dead now (in fact, this version of
auth_x11 would work fine if passed the saver window ID instead).

Or maybe just a minor change to auth_x11 to behave as if there's only
one monitor all the time, while keeping the dialog on the current one...
let's see later.

- Auth window is still always on top.

- Auth window is now a child of the background window, not of the saver
  window.

- Thus, auth window now overlaps the saver window; thus all overlap
  protections for that window have been removed. In worst case something
  may now overlap the saver that we don't want; our protections still
  kick in if it also overlaps the background window (so there's only an
  issue if a saver is misbehaving).

Now auth helpers can create sibling windows; useful for multi-window
auth (be it for showing a windowed prompt on all screens while letting
the saver shine through, or be it for showing a "taskbar" at the bottom
to allow mouse based actions).

This change is compatible to existing auth helpers.

We only do this in order to restart the blanking timer; if savers
implemented a different protocol for this (e.g. SIGUSR1), this could go.

Don't want this to be confused with success.

Note: this can actually never happen on Linux.

Add basic support for playing sounds during the auth flow.

Use XSECURELOCK_AUTH_SOUNDS=1 to turn them off. Requires a working X11
bell (usually provided on Linux by the pcspkr kernel module).

Also, always run the player with a playlist of 256 videos; this strikes a
balance between having too many pauses between videos while not eating
too much memory in the player.

Replaces pull request #56.

README said it was enabled, but it's disabled by default.

Mainly because some people found it annoying to include the seconds there, but there's no portable way to remove them.

Fixes #57.

This allows easier building from outside a git repository; however, the
value should still either be based on a git revision or tag the build is
based on, or explicitly say that there is no correspondence to a
released git revision (e.g. by passing something like
VERSION='(ask pacman instead)') if necessary.

Fixes #59.

The only functional difference is that in XSECURELOCK_FORCE_GRAB=1 mode,
the new code will be holding a server grab while grabbing input even if
it detected another xsecurelock instance.

However, this difference is minor, and makes the code a lot more
readable.

Now compiles on Debian oldstable again.

Multiple screen lockers can interfere in various ways:

- First of all, log spam: only the first locker is usually able to lock at all. Any others will usually fail getting the required input grabs.

- Some lockers, e.g. light-locker, also have specific countermeasures against failing to lock and may interfere with xsecurelock. This has in the past caused issues such as having to unlock twice, having to unlock on a black screen because the graphics output broke, or losing all input focus after unlocking (yes, including alt-tab) and thus having a broken environment until clicking another window.

- Also, potential race conditions during startup of both at the same time might cause deadlocks (e.g. if one grabs mouse first and one grabs keyboard first, while retrying indefinitely).

- Even if they're not retrying indefinitely (xsecurelock isn't), this can slow down suspend to the point that systemd gives up and suspends before the screen is locked.

Looks better.