Restrict the rdpgw-auth socket to its own UID by default (#190)

The auth daemon's gRPC socket was world-writable and accepted any
local UID that could connect to it. On a multi-tenant host any user
on the box could speak the gRPC API and run an arbitrary username/
password through PAM -- effectively an unauthenticated PAM oracle.

Create the socket with mode 0660 (Umask(0117)) and gate Accept on
SO_PEERCRED: only the daemon's own UID is allowed by default, plus
any operator-supplied --allow-uid / --allow-gid. Privilege-separated
deployments (rdpgw and rdpgw-auth as different users) need to list
the gateway's UID, or share a group; the existing path otherwise
would have been permissive.

The peer-credentials check is Linux-only; the non-Linux build keeps
the listener as-is and logs a warning, since rdpgw-auth itself
requires libpam and is effectively Linux-only in practice.

docs/pam-authentication.md

@@ -69,6 +69,23 @@ Run the `rdpgw-auth` helper program:
 systemctl start rdpgw-auth
 ```
 
+### 4. Allow the gateway process to call the socket
+
+`rdpgw-auth` only accepts connections from its own UID by default. If
+the rdpgw process runs as a different user, list its UID (or a shared
+GID) explicitly:
+
+```bash
+# rdpgw runs as UID 1001
+./rdpgw-auth -s /tmp/rdpgw-auth.sock --allow-uid 1001
+
+# rdpgw and rdpgw-auth share group 'rdpgw' (GID 1100)
+./rdpgw-auth -s /tmp/rdpgw-auth.sock --allow-gid 1100
+```
+
+The socket itself is created with mode `0660`, so listing a shared GID
+on the daemon is the typical privilege-separated deployment.
+
 ## Authentication Flow
 
 1. Client connects to gateway with username/password