 |
 |
hi @gganis , thank you for taking a look. I'll try to summarise the changes for XrdSecProtocolgsi and my reasoning, below: (i) Store an exported version of the new delegated proxy request's private key in hs->Cref->buf4, rather than a XrdCryptoRSA*. This is so that the 'buf4' destructor (~XrdSutPFBuf) can free this storage. In the previous situation, once the client signs the delegated proxy and returns it to the server, the EVP_PKEY* inside buf4's XrdCryptoRSA* gets shared with a XrdCryptoX509 object. That latter should eventually be deleted, which also takes care of the EVP_PKEY, but the XrdCryptoRSA object in buf4 leaks. (Indeed it can't be free-ed as it would also try to double free the EVP_PKEY). In case something goes wrong and the dialogue fails before the signed delegated proxy is processed, the XrdCryptoRSA and its EVP_PKEY leaks. (See bottom of comment for a case where the dialogue can fail *) (ii) Added flag so that ~gsiHSVars() can cleanup and delete PxyChain member. I think, in the server this should only be set in the interval between delegated proxy request generation by the server and receipt of the signed version from client; but (similar to (i)) if the dialogue is interrupted it leaks. On the production service I could see indication that this does happen quite frequently. (See below *) (iii) Added PxyChain->Cleanup(); in a few places; this was because I had added similar code in ~gsiHSVars, so did so in the few other places. I used the 'keepCA=false' default parameter, as I understand the issue of keeping the first certificate in the chain, if it is a CA, is because in the case of hs->Chain, the first certificate is a CA certificate from our cache, so shouldn't be freed. But the gsiHSVars::PxyChain (or XrdSecProtocolgsi::proxyChain, once it is moved there) doesn't share with the cache, so I don't believe the exception is needed (but indeed the first cert in the delegated proxy chain probably is not a CA, and so this makes no difference). I changed this in one existing place, in XrdSecProtocolgsi::Delete() for proxyChain->Cleanup, for the same reason. (*) On one production server there are quite frequently message like: 230613 17:03:19 223031 secgsi_Authenticate: buffer with requested info missing :Not allowed to sign proxy requests (which have not reported as problematic, and wasn't really the subject of the current issue, but indicated some other paths are often taken, which can also leak). On a development xrootd standalone server I could reproduce this server side error message by using an old client (e.g. v 4.9.0) and using the server's IP address rather than name while requesting delegation. e.g. ./src/XrdCl/xrdcp --tpc delegate first root://1.2.3.4//afile /dev/null -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/2029#issuecomment-1589615661 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1