Purging the agent's security token

Jay Shaughnessy jshaughn at redhat.com
Tue Dec 18 14:00:05 UTC 2012


On 12/18/2012 8:49 AM, Jiri Kremser wrote:
> Hi,
>    I would like to implement this feature Jay originally proposed. The idea is that it should be possible, for the authorized user (MANAGE_SECURITY), to invalidate an existing security token for any reason (mostly agent/db upgrade). Invalidating the token means setting its value to something like @#$reset$#@, and storing it to the DB for an agent with name "A". Next time the agent "A" tries to register, server finds out the token in the DB is willing to be updated with the agent's actual token. And stores it into DB instead of temporary marker "@#$reset$#@".
>
> There are still some questions to discuss:
>
> 1) When clicking on the button for purging the existing token, should be the agent disconnected/reconnected or is it ok to continue in this quite undef state?
I would guess that if a reset is necessary it is because the agent can't 
connect in the first place.  But, if the agent were connected I think 
the reset could take place anyway.
> 2) Are there any edge cases in this approach? For instance if attacker provides -Drhq.agent.security-token=@#$reset$#@ on purpose (this can be easily handled).
I'm not sure I understand the need for system property to be involved in 
this workflow.  The reset mechanism can be internal, I think.
>
> 3) Possible race condition when registering the different 2 agents with the same name when the token is invalidated for this name.
> ..
>
> Here is the BZ for it https://bugzilla.redhat.com/show_bug.cgi?id=888016
I don't think this is an issue.  The first to register should succeed, 
the second should fail, not unlike standard agent-token storage.
>
> JK
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list