Nathan,
On 4/21/16 2:17 AM, Nathan Scott wrote:
diff --git a/src/pmcd/src/pmcd.c b/src/pmcd/src/pmcd.c
index 7d292e4..f129f6e 100644
--- a/src/pmcd/src/pmcd.c
+++ b/src/pmcd/src/pmcd.c
@@ -660,6 +660,8 @@ CheckNewClient(__pmFdSet * fdset, int rfd, int family)
cp->pduInfo.features |= PDU_FLAG_COMPRESS;
if (__pmServerHasFeature(PM_SERVER_FEATURE_AUTH))
/*optional*/
cp->pduInfo.features |= PDU_FLAG_AUTH;
+ if (__pmServerHasFeature(PM_SERVER_FEATURE_CERT_REQD)) /*required*/
+ cp->pduInfo.features |= PDU_FLAG_CERT_REQD;
if (__pmServerHasFeature(PM_SERVER_FEATURE_CREDS_REQD))
/*required*/
cp->pduInfo.features |= PDU_FLAG_CREDS_REQD;
if (__pmServerHasFeature(PM_SERVER_FEATURE_CONTAINERS))
OK, This all makes sense. Thanks for the pointer to this code.
A quick audit of those suggests - there should probably be a command line option
to pmcd for this, pmproxy might not need to know anything about it?,
I initially had looked at doing a command line option to pmcd, but it
looked to me to require some invasive work to get that down to the
secure* files. But probably the right thing to do. Will look again. I
think the pmServerFeature stuff will help here if I understand it correctly.
I think that is correct in the case of pmproxy. It would forward this
new PM_SERVER_FEATURE_CERT_REQD to the client.
At the client end, regardless of whether or not pmproxy is in the mix,
if a CERT_REQD is received and the client was not invoked with
"PCP_SECURE_SOCKETS=enforce" should that be an error? Or should we try
to upgrade the connection?
and there's
that pmcd.feature metric we should add. That will help with QA - the tests can
(if they need to) query support using pmcd.feature.cert_required (or whatever we
end up choosing for a name) - see the tests using qa/common.secure as examples.
Sounds good
In terms of docs, the PCPIntro(1) man page would warrant an update with the new
environment variables (esp. those influencing client behaviour), and a tutorial-
style discussion in lab.secure.html would be excellent.
Of course. I've got most of this in a rough form, since I've been going
through it over and over again in testing.
BTW, looks like there's an unused variable that crept into pmproxy in the series
of commits ("hostName").
Yup, missed that in some code cleanup.
Finally, I noticed that pmproxy by default uses /etc/pki/nssdb for both
client and server connections. Since this directory is usually owned by
root and pmproxy usually runs as the pcp user, it can't store supplied
certificates there. So i went looking for an existing directory I could
pass in with the "-C" option to pmproxy. The best I could find was
/var/lib/pcp/tmp. Any thoughts on a better place? Maybe create a
pmproxy directory under /var/lib/pcp/config?
There is precedent for /var/lib/pcp/config directories to be pcp:pcp owned, so
I'd suggest that's the better option (tmp sounds a bit too temporary for this,
to me anyway).
Does it need to be accessible/writable by other daemons like pmcd too? (pmwebd
someday, perhaps?) - if so, maybe a generic spot like /var/lib/pcp/config/nssdb
would suit? Not sure.
Yeah, that probably makes sense. This could be used by any server side
process that runs as the pcp user. So pmcd and pmproxy for sure.
Thanks for the notes.
Martins
|