Add PAM_RUSER format specificier

[msantos]

Add a new "%r" format specifier to represent the PAM remote user:

auth sufficient pam_ssh_agent_auth.so file=/etc/keys/%r

This change allows programs, like su, that set RUSER to the origin user
and USER to the destination user, to name the key according to the user
calling the program:

# auser -> root
/etc/keys/%r # equivalent to /etc/keys/auser
/etc/keys/%u # equivalent to /etc/keys/root

[jbeverly]

I would add an explanation here that the file must still belong to root/the target user and cannot be writable to the RUSER (Ownership is checked by auth_secure_path, so misuse cannot lead directly to a bypass; but it won't work).

[msantos]

Thanks, updated:

@@ -81,6 +81,10 @@ Automatically enables allow_user_owned_authorized_keys_file

 =item %r -- Remote Username

+Allows programs like su that set RUSER to the origin user and USER to the destination user, to name the key according to the user calling the program.
+
+The key file must belong to root or the target user. It must not be writable by the RUSER.
+
 =item %f -- FQDN

 =back

[AlD]

The key file must belong to root or the target user. It must not be writable by the RUSER.

This logic is backwards. There may be cases where it's acceptable for this file to be writable by RUSER. There are no cases where the originating user should be able to write to this file. See also #17.

[AlD]

No, you're actually right. According to sudoers/auth/pam.c RUSER is actually the 'from' user, just as you wrote.

Set PAM_RUSER to the invoking user (the "from" user).

My confusion, and apparently that of the person who originally reported #17, comes from the fact that ruser and user somehow end up being identical when invoked via sudo. Not sure where that bug comes from, but a safeguard against this in pam_ssh_agent_auth could make sense.

[msantos]

specificier -> specifier