ssh-agent: perform AGENTC_REMOVE_ALL_IDENTITIES on SIGUSR1

[Steffen Nurpmeso]

Dear Peter Stuge.

Peter Stuge wrote in
 <20210911164735.15145.qmail at stuge.se>:
 |Steffen Nurpmeso wrote:
 |> So with these two there is the security guarantee you were asking
 |> for, that the removal happens instantly.
 |
 |Sorry but no, as long as the trigger is a signal there's no guarantee.
 |See below.
 ...
 |> But why so Peter?  Signals are used for communication on Unix since ever?
 |
 |In your stated use case of suspend on laptop lid close there is a race
 |condition between the actual suspend and SIGUSR1 being handled in agents.
 |
 |The ACPI script runs various commands to prepare for suspend, one of
 |them would be pkill or killall. That command would find all agent
 |processes and call kill(2) to send SIGUSR1 to each one.
 |
 |There's a race because signal handling is asynchronous.

Yes.  Well ... yes.
Actually it is worse since we do

  act() {
     logger -t /root/bin/zzz.sh "$*"
     eval "$@"
  }

  act 'SSH_AUTH_SOCK="$a" ssh-add -D </dev/null >/dev/null 2>&1 &'

to be eventually replaced by

  act 'pkill -USR1 ssh-agent </dev/null >/dev/null 2>&1 &'

Especially on those fewest-CPU systems where the parent continues
to run until it no longer can :)

Note i already do

  act 'pkill -TERM --full setup-privacy.sh </dev/null >/dev/null 2>&1 &'

for good.

  ...
 |Consider as an exaggerated example the pkill/killall command being the
 |very last command in the ACPI script before echo mem > /sys/power/state
 |and a system with two CPU threads and 100+ running agents.

But this is not the way it is done here.  If anything had to
happen, like unmounting encrypted directories, we are sleeping
a while.  That is three seconds at the moment.  Which is a very,
very long time on a modern computer that does the work this thing
here does.  Also it _then_ really syncs and sleeps in between the
syncs thereafter.  It is an interesting thing however, maybe one
should pgrep first and count how many agents will be contacted.
Interesting.

  ...
 |I see that a bit differently: I find it interesting to look in code that
 |I don't know, because I may learn from it.

That sometimes happens indeed.  But very rarely in user space code
i really have to say.  Mostly i get frightened how much code can
be soiled.  For example yesterday i looked in shadow's login.c,
and was almost on side-by-side comparison with FreeBSD's one, and
then also busybox's one.  (In order to find out whether it would
make sense to provide a pam_session_reaper module in order to be
able to handle sessions gracefully without systemd.  Not for the
former).  It is an experience!  You become a BSD fan.

Or for example today i have seen a zstd code addition request to
busybox, and it was the first time in at least 17 years that
i have seen C code that uses p2align asm() statements to
code-align loop starts (i only ever did so in assembler), and
comments like "better for gcc-9 and gcc-10, worse for clang and
gcc-8, gcc-11".  It seems if you work for Facebook you have quite
some systems and combinations for testing.  (I did such stuff
myself by then, really!)

 |You're right that it requires effort, but so does working with my own \
 |code. :)

Yes.  Yes.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)