Add locking when adding aliases to existing entities #4965
Conversation
vault/identity_store_entities.go
Outdated
| @@ -332,6 +332,11 @@ func (i *IdentityStore) pathEntityIDUpdate() framework.OperationFunc { | |||
| return logical.ErrorResponse("missing entity id"), nil | |||
| } | |||
|
|
|||
| // Acquire the lock to modify the entity storage entry | |||
| lock := locksutil.LockForKey(i.entityLocks, entityID) | |||
There was a problem hiding this comment.
I think you need to add this in pathEntityRegister too since it also calls handleEntityUpdateComon.
There was a problem hiding this comment.
The only case left in pathEntityRegister is new entities since when the id is provided it comes through this method.
There was a problem hiding this comment.
Yes, but you changed the function in handleEntityUpdateCommon to use a non-locking version, and now if it goes through pathEntityRegister and don't provide an ID that function is called without a lock.
There was a problem hiding this comment.
I added back the lock on a new entity by calling upsertEntity for new entities.
vault/identity_store_aliases.go
Outdated
| @@ -206,19 +206,10 @@ func (i *IdentityStore) handleAliasUpdateCommon(req *logical.Request, d *framewo | |||
| } | |||
|
|
|||
| // Get entity id | |||
| canonicalID := d.Get("entity_id").(string) | |||
| canonicalID := d.Get("canonical_id").(string) | |||
There was a problem hiding this comment.
Can you also put a deprecation notice for entity_id's pathHelp?
vault/identity_store_aliases.go
Outdated
| lockKeys = append(lockKeys, existingEntity.ID) | ||
| } | ||
|
|
||
| if canonicalID != "" { |
There was a problem hiding this comment.
If you move lockKeys up to the top and add in the canonicalID up then, if we have one, you can pull the LocksForKeys and lock/unlock lines out of this if/else
vault/identity_store_aliases.go
Outdated
| @@ -256,6 +247,51 @@ func (i *IdentityStore) handleAliasUpdateCommon(req *logical.Request, d *framewo | |||
| return nil, err | |||
| } | |||
|
|
|||
| var existingEntity *identity.Entity | |||
| var lockKeys []string | |||
| if !newAlias { | |||
There was a problem hiding this comment.
I think this part should be after the locks are grabbed. The MemDB stuff happens in a transaction but it's still possible for that transaction to say, for instance, that there is no existingEntity, then have such an entity be created after the locking.
There was a problem hiding this comment.
Unfortunately, we don't know the id of the entity to grab the lock for. This is what I alluded to as still a race but since we have to look it up, I'm not sure the alternative.
There was a problem hiding this comment.
One way to alleviate this issue would be to add locks for alias IDs. I'll went down that path at one point but pulled it out since it was only really used here. I think that would fully take care of this issue and will do that.
vault/identity_store_aliases.go
Outdated
| if existingEntity == nil { | ||
| return nil, fmt.Errorf("alias is not associated with an entity") | ||
| } | ||
| lockKeys = append(lockKeys, existingEntity.ID) |
There was a problem hiding this comment.
Is it possible that canonical_id and existingEntity.ID can be the same ID, i think they can if you're updating the alias and keeping the same entityID. If so i think the below lock acquisition will deadlock
There was a problem hiding this comment.
Actually it looks like the LocksForKeys function will dedup them for you
vault/identity_store_aliases.go
Outdated
| @@ -256,8 +258,46 @@ func (i *IdentityStore) handleAliasUpdateCommon(req *logical.Request, d *framewo | |||
| return nil, err | |||
| } | |||
|
|
|||
| var existingEntity *identity.Entity | |||
There was a problem hiding this comment.
Don't you need to grab the alias lock before the MemDBAliasByFactors call above? Otherwise what happens if an automatic call is registering an alias at the same time as this manual call?
vault/identity_store_aliases.go
Outdated
| if entity == nil { | ||
| return logical.ErrorResponse("invalid canonical ID"), nil | ||
| } | ||
| } |
There was a problem hiding this comment.
After this it should probably check again to see whether the Alias is still a part of this entity.
Fixes #4870