I run xtrlock on a machine which doesn't store all its passwd/shadow
entries locally. So xtrlock is unable to verify my password by the usual
method.

To get around this, I added a feature which replaces the passwd/shadow
based check with a user-provided subprogram. xtrlock pipes the password
into the subprogram's standard input, and unlocks the screen if the
program exits with a success status.

I can make this check my real login password by using a subprogram based
on 'su $USERNAME -c true' (with some plumbing to run it in a pty and
pipe the password through). Another obvious approach would be to define
a 'screen-unlock password' separate from my login password, and a
subprogram that checks that (say, against a file containing a crypt(3)ed
version). This also means that xtrlock can do something useful even in
situations where someone is not able to give it set-id access of any
kind.

The only problem I've found with this is that the su-based check takes
noticeable time (several seconds in the environment where I use this),
so that I start wondering whether I got my password wrong, or whether
it's just being slow to check. To work around _that_, I've also arranged
to temporarily turn the mouse pointer from a padlock to an hourglass
while the check program is running.

Both patches are attached. At the moment, they lack documentation, and
also the hourglass-pointer patch is unconditional rather than
configurable. I'm prepared to do extra polishing effort if it's useful!

Cheers,
Simon

Simon Tatham <anakin@pobox.com> wrote:

Now I look at the existing bug list, this might provide functionality
related to two existing bugs:

 - #84419 xtrlock won't work with NIS/shadow maps

   This is exactly what I use it for, and it avoids complicating
   xtrlock itself any more than necessary. Perhaps the direct PAM-based
   check the reporter suggested could be turned into a more polished
   version of my horrid su-based check script, although I don't know how
   to do that off the top of my head.

 - #806734 xtrlock: add custom passphrase

   The requester wanted to prompt for a passphrase at startup, but
   perhaps having one configured in advance is at least good enough, and
   maybe even better? (If you use the same passphrase all the time, it'd
   be embarrassing to make a typo when leaving your desk, and then not
   be able to get back in.)

Cheers,
Simon

Hi,

Thanks for this and the attached patches; I think it's a useful addition
to xtrlock.

I think both docs and making the hourglass optional would be good,
please; I'm sorry I've not done anything more useful in terms of review
yet, but I'm currently a bit swamped, and I thought at least some reply
would be better than continued silence!

Regards,

Matthew

Matthew Vernon <matthew@debian.org> wrote:

Revised patches attached.

The runtime usage message was starting to get large, so I've appended a
third patch that sets up standard --help and --version options, in case
that's also useful to you.

Cheers,
Simon