Hi, I've noticed that condor_reconfig and security settings interact very poorly. In the latest Condor, my best recommendation is: if you change security settings, never do "condor_reconfig" or "condor_restart" - restart with "service condor restart". It's frustrating to not be able to use restart/reconfig. Basically, when you change settings such that previous security session is no longer valid (my example is when we switched from IP based security to GSI based security), the security sessions continues to be used. In my case, the condor_master was no longer able to speak to condor_schedd because the condor_master kept using the same (valid, but no longer authorized) security session. I would argue that security sessions need to be reset when condor_reconfig is done (or if Condor is smart enough to only do it when security sessions have changed, that's fine too). So, in my case, the condor_schedd would tell the master its session should be invalidated. This would solve the issue at hand, but there are some things to think about: 1) condor_reconfig can be triggered with only WRITE access; someone with WRITE access could trigger arbitrary reconfig and have an impact on security sessions. This starts to sound like the basis of a "TCP RST"-like attack. 2) Can we securely invalidate sessions? I don't know this, but it feels like there would be some difficult issues here. Brian
Attachment:
smime.p7s
Description: S/MIME cryptographic signature