Hi guys,
[note: this mail quickly got very long - there are specific
points that are more relevant to each of your projects near
the end but lots of context is needed first though... sorry
'bout that!]
Following is a series of useful tidbits that I've found
while hacking on SASL2 and the PCP protocol extensions for
user authentication. It's intended to help particularly
around debugging connection establishment which can be very
obtuse/tricky at this stage.
As per earlier mail on the topic, authenticated connections
are setup using connection attributes - to establish such a
connection, one makes use of an extended host specification
syntax (typically via -h option on client tools). Without
this host syntax, regular non-authenticated connections are
always made at this stage.
This syntax is an (optional) protocol type, then a hostname
and (optional) port, and then attributes for the connection.
For protocol type either "pcp" or "pcps" is allowed (native
"pcp" protocol being the default). Use of "pcps" triggers
secure sockets mode, and requires certificate setup on the
pmcd host as per the secure sockets tutorial.
I mention "pcps" here only because AIUI some authentication
methods require a secure connection (SASL enforces this).
Now to trigger a SASL authentication attempt, we need to
make use of an attribute that indicates this. Presence of
any of the auth attributes in the host specification (for a
complete list see src/libpcp/src/spec.c::__pmAttrKeyStr_r &
__pmParseHostAttrsSpec). As commented at the head of the
latter routine, some example hostspecs that would trigger
an authentication attempt would be:
pminfo -h pcp://oss.sgi.com:45892?user=otto&pass=blotto
pminfo -h pcps://oss.sgi.com@xxxxxxxxx:45893?user=jimbo
Backing up a bit, SASL allows us different authentication
method choices - e.g. gssapi, login, etc ("mechanisms" in
SASL terminology). Once an authenticated connection has
been requested, SASL will choose the method on our behalf
if we do not specify which we prefer for this connection
(i.e. can request the method from the client-side).
When we reach the authentication stages of a PCP protocol
exchange, the server initially sends the client a list of
available authentication methods. Then the client selects
one (via method=xxx connection attribute, or automatically
within libsasl) and sends that back to the server. Then a
number of zero or more round-trips ensue, where the server
authenticates the client - using usernames, passwords,
gssapi kerberos-fu, whatever - depending on the selected
method. In the absence of needed authentication info from
hostspec attributes, SASL will invoke callbacks to aquire
missing information (like passwords and so on).
Natually, all sorts of things can go wrong and it depends
on the method selected as to why/where. I've found it to
be very handy to make extensive use of the -D AUTH tracing
flag to get at additional information. This flag is used
on both client and server side (/etc/pcp/pmcd/pmcd.options
for the latter, directly on command line for the former).
Even with that, its not usually easy to debug - something
we'll need to work on further.
So, here's a sample invocation using secure protocol and
the SASL "anonymous" authentication method (best to start
with this, no password needed):
$ pminfo -DAUTH -f -h pcps://verge?method=anonymous\&user=anonymous hinv.ncpu
WARNING: issuer of certificate received from host verge is not trusted.
SHA1 fingerprint is BD:48:A1:B6:AD:7E:2D:66:73:38:24:C7:58:E9:33:20:41:9B:5B:90
Do you want to accept and save this certificate locally anyway (y/n)? y
__pmAuthClientNegotiation(fd=1024, ssf=128, host=verge)
__pmAuthClientNegotiation requesting "anonymous" method
__pmAuthClientNegotiation got methods: "DIGEST-MD5 NTLM CRAM-MD5 LOGIN PLAIN
ANONYMOUS" (46)
__pmAuthSimpleCB enter ctx=0x19de1a8 id=16385
__pmAuthSimpleCB ctx=0x19de1a8 id=16385 -> sts=0 rslt=0x19de2d0 len=-1
sasl_client_start chose "ANONYMOUS" method, saslsts=ok
sasl_client_start sending (25 bytes) "ANONYMOUS"
__pmAuthClientNegotiation success, username=anonymous
hinv.ncpu
value 2
Yay! Successful authentication and ultimately values
are returned. On the server side with -DAUTH logging
enabled /var/log/pcp/pmcd/pmcd.log contains:
__pmSecureServerIPCFlags SASL server: 0
__pmAuthServerNegotiation(fd=1027, ssf=0)
__pmAuthServerNegotiation - sending mechanism list (6 items, 48 bytes): "PLAIN
ANONYMOUS CRAM-MD5 GSSAPI LOGIN DIGEST-MD5"
__pmAuthServerNegotiation - wait for mechanism
__pmAuthLogCB enter ctx=(nil) pri=4
[Thu May 30 14:21:05] pmcd(31492) Notice: ANONYMOUS login: "nathans@smash"
sasl_server_start success: sts=ok__pmAuthServerNegotiation method negotiated
[Thu May 30 14:21:05] pmcd(31492) Info: Successful authentication for user
"anonymous"
Once an authenticated connection is established, pmcd
will extract attributes it knows about (currently user
name, uid and gid, IIRC) and passes those on to any of
its PMDAs that have expressed an interest).
Some other random notes: for your unix-domain-socket
authentication efforts, Dave, you don't need to know
about SASL (I think), just connection attributes - I
believe we will be able to set PCP_ATTR_USERID and
PCP_ATTR_GROUPID (see SO_PASSCRED on unix(7) man page)
from within pmcd for a connection. See the ClientInfo
structure in pmcd which has an attribute hash for each
connection ... we will want those two attributes set
automatically for all unix domain connections.
For the pmwebd authentication efforts Frank there's a
__pmUnparseHostAttrsSpec() as well which takes a hash
of attributes (presumably built up from corresponding
attributes within the http URL, or via a POST) which
produces the extended hostspec format, which will be
needed for establishing the pmwebd/pmcd connection on
behalf of that web client.
Have fun!
cheers.
--
Nathan
|