There are many different PAM implementations out there, which I haven't
all tested. The PAM service name is used to build a path name, typically
inside /etc/pam.d, to find a service configuration file.

There's a possibility that in some PAM implementations, the service name
is not sanitized and could be used to traverse paths; as most PAM
clients are _not_ setuid and do _not_ let the caller specify the service
name (unlike xsecurelock), this alone wouldn't be a vulnerability per se.

And successful path traversal could e.g. lead to attackers obtaining
information about existence or nonexistence of files they can't see, or
possibly even reading part of a file (e.g. a PAM implementation might
spit out syntax error messages quoting parts of a file, either over
[possibly sniffable] syslog or to stderr; the latter would then allow an
attacker to run

XSECURELOCK_PAM_SERVICE=../shadow ./authproto_pam

to dump the root password hash.

Again, I'm not aware of any system where this exploit would actually
work - but as the PAM specs I have here do not describe what happens if
a PAM service name contains a slash (Linux PAM appears to use the
basename then), I've decided to just refuse any such names.

Fixes compile on OpenBSD.

Confirmed working on OpenBSD now, assuming you make authproto_pam setgid auth.

Fixes build on OpenBSD.

This allows authproto with interactive terminal input which is line
buffered. Of course this would only happen during testing, but fixing
anyway.

This can be used for fuzzing with afl-fuzz, so we can be somewhat
assured the code used by authproto_pam.c is fine; after all, on FreeBSD
this has to run as setuid root.

We still include explicit lengths so the reader only needs to allocate
the buffer once, but the protocol is now simple enough to run "by hand",
which is nice for debugging or implementing your own in a different
language than C.

This is now used by auth_pam_x11 as sole backend. It can be made
setuid/setgid where necessary to authenticate local users (e.g. on
FreeBSD).

Also renames auth_pam_x11 to auth_x11, and moves auth_htpasswd and
auth_pamtester to authprotos that can be used with auth_x11.

Will fix #43.

Fixes build warning on FreeBSD.

A header added by IWYU does not exist on FreeBSD; turns out it's not
meant to be explicitly included anyway.

The keybind for it is Ctrl-Tab, which seems to be one of the few that:

- Don't emit a keycode usable in a password.
- Aren't selectable as Xkb modifier (as that would cause us to swich
  twice, which with 2 layouts would be a NOP).
- Are available on all layouts and keyboards I know.

Thanks to Soumya S. for an initial implementation of this, which I've
ported into auth_pam_x11!

It's no longer in master after all.

Behavioral changes/fixes:

- Whitespace skipping now is performed in all appropriate places.
- Visual skipping now happens on the same set of visual names.
- Quoted arguments in commands now work. In fact, so do all other shell
  characters.

One remaining difference though (intentional):

- The program name itself can't be quoted.

This serves to handle cases such as PAM asking the user to authenticate
to an external device by asking the user to do something with
PAM_TEXT_INFO then waiting for the user to do so; we then want to keep
PAM's message on the screen until the action happens.

Of course, we still do show the processing message if the last action
was an entry dialog (e.g. password entry).

Also changes on some systems the events on bad password entry:

- Before: Password:, Processing..., Invalid Password, Processing... (sleeping 2 seconds)
- After: Password:, Processing..., Invalid Password (sleeping 2 seconds)

This gives users more time to read the error message.

Yes, this means auth_pam_x11 may instant time out when the clock is
stepped forward by NTP. Trying this out anyway, as:

- This should only be an issue if the clock is stepped forward by more
  than few minutes, as the timeout defaults to 5 minutes.
- We also put in a specific counter measure against the clock stepping
  backwards - when it does, we simply reset the timeout.

Advantage: that way, auth_pam_x11 will almost always exit on resuming
from suspend state. This is very desirable so we can control visibility
of the hostname in a wrapper script.

Now that it's 1px smaller from all sides, not only should it not cause
unredirecting (and thus unmapping of the COW) anymore - even better,
it's forced to be above everything else, so it can even prevent
unredirecting in case a full-screen application is running, and thus
makes sure that the COW stays alive.

I need it for my Bspwm setup ;)

- Work around Bspwm issue by explicitly never unmapping Bspwm-owned
  windows. Also remove incompatibility note about it.

- Don't unmap windows owned by this process.

- When detecting an xsecurelock-owned window that's not of the same
  process, disable forcing to prevent harm from the screen already being
  locked.

The option is quite intrusive, and the documentation states "use with care", so I think it makes sense to default it to off.

It's now hidden behind a #define that's not enabled by default.

It simply shouldn't be necessary unless there are driver bugs, and given
auth_pam_x11 draws at low fps it's not very effective at hiding
information leaks (like the one we discovered recently involving
Cinnamon crashing) anyway. On the other hand it may use quite a lot of
CPU power, especially on low-end systems.

Effectively reverts 6b1b4f4e.

XSECURELOCK_FORCE_GRAB=1: locate all client windows, hide them, grab,
unhide them. Will very likely rearrange them, but otherwise works with
most WMs.

XSECURELOCK_FORCE_GRAB=2: locate all windows below the root window, hide
them, grab, unhide them. Will solve some cases =1 does not, but probably
breaks most WMs.

When reinstating grabs isn't enabled (it's currently hardcoded on), still do retry every frame if it failed.

It's only meant as a fallback in case of compositor misbehavior, and
making it smaller adds compatibility with Cinnamon's compositor
(Muffin), which will then no longer unredirect in response to
xsecurelock starting.