[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[HTCondor-users] Authentication code refactor
- Date: Sat, 09 Apr 2022 12:28:32 +0300
- From: Marco van Zwetselaar <zwets@xxxxxxxxxx>
- Subject: [HTCondor-users] Authentication code refactor
Dear Cole / devs,
On 09/04/2022 04:20, Marco van Zwetselaar wrote:
Thanks for digging into this. The various revisions and comments
("hack for now") surrounding daemon vs user and server vs client in
the authentication code suggest a long history of organic growth :-)
and you may need to start with some conceptual clean-up.
I've given this some thought. My hunch is that the main design issue
with the Condor_Auth class (hierarchy) is that too many responsibilities
have crept into it. It is expected to figure out "on its own" at which
end of the peering it is operating (client or server), and, when client,
on behalf of what principal (user or condor).
The class currently tries to derive this from both dynamic (am I running
as root?) and structural information (am I integrated in a daemon
component?), and this gets confusing as it needs to draw different
conclusions in different code paths (hence the "hacks").
The solution would probably be to explicitly pass the relevant
information to Condor_Auth, in its constructor for structural
properties, and as an argument to authenticate() for behaviour that
depends on runtime context.