Token lookup via accessor returns the properties of another accessor

[Caiyeon]

Disclaimer: This bug is reproduced by programatically launching the vault core.
Description: The launched dev core has one accessor that, when looked up, refers to another accessor.

$ vault list auth/token/accessors
Keys
----
83be5a73-9025-1221-cb70-4b0e8a3ba8df
bbed2bd7-fc8e-a89e-b8b8-f09d92de5a27
f043b145-7a63-01db-ea85-9f22f413c55e

$ vault token-lookup --accessor 83be5a73-9025-1221-cb70-4b0e8a3ba8df
Key             	Value
---             	-----
accessor        	bbed2bd7-fc8e-a89e-b8b8-f09d92de5a27
creation_time   	1498260999
creation_ttl    	0
display_name    	token
expire_time     	<nil>
explicit_max_ttl	0
id              	
issue_time      	2017-06-23T16:36:39.642533742-07:00
meta            	<nil>
num_uses        	0
orphan          	false
path            	auth/token/create
policies        	[root]
renewable       	false
ttl             	0

Note the difference between the accessor in command and returned value.
The code that launches the vault core can be found here https://github.com/Caiyeon/goldfish/blob/master/config/dev.go#L154

If you want, you can pull the repo and run go run server.go -dev. Vault will be accessible at http://127.0.0.1:8200 with root token goldfish. This is reproducible in minutes

[jefferai]

Is it reproducible with a normal Vault dev server?

[Caiyeon]

Not as far as I've tested. I've only been able to reproduce this by launching the core programatically

[Caiyeon]

Oh, I see what's happening. I launched the core with a dev root token, and then I created another root token and forced the same ID on it. So there's two accessors, that lead to the same ID. I imagine this is not a problem with UUIDs, but is this the expected behaviour?

Can be reproduced with normal vault server by just creating two tokens with the same ID (root token required)

[jefferai]

I'm scheduling this to fix as a bug in that we shouldn't allow the same ID to be used multiple times. But it's also not at all something you can do in the normal case (and really, we've been planning to take out the ability to ever specify the ID for a while, and may deprecate it with 0.8 and see if it's going to completely screw with anyone).

[Caiyeon]

I see, makes sense! Would removing id parameter imply removing the ability to force root token id with a dev server?

[jefferai]

No, we'd keep that as it's super useful for dev.