mirror of
https://github.com/ovh/the-bastion.git
synced 2026-05-09 08:25:27 +02:00
[GH-ISSUE #363] Deleted account name and uid blocked #98
Labels
No labels
answered
bug
documentation
enhancement
enhancement
feature
feature
kept-open-for-info
pull-request
question
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/the-bastion#98
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Pierrelefort on GitHub (Feb 22, 2023).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/363
Hi,
I am currently working on a terraform provider for thebastion. His main goal is to manage users of thebastion with terraform state.
During my testing phase, i created an account with these parameters: "name": "test", "uid": "99992". But, since i deleted it, those parameters seem to be locked. I am unable to create a new account with this name or this uid. This account named "test" is not visible on the return of accountList command. Any idea how to fix this ? And why did it happen ?
Provider accountCreate command: "--osh accountCreate --account test --uid-auto --no-key"
Provider accountDelete command: "--osh accountDelete --account test --no-confirm --json"
Screenshots:



@Pierrelefort commented on GitHub (Feb 27, 2023):
UPDATE: My custom terraform provider create two accounts using the "--uid-auto" option. Both tried to create an account with the same uid, creating an error. But, i don't know why the bastion has blocked the name or the uid.
@speed47 commented on GitHub (Feb 28, 2023):
Hey @Pierrelefort ,
Nice to hear that you're working on a terraform provider! This is actually on my backlog because we also have the need internally, especially to handle add/removing of IPs in bastion groups (in that case, the account used by terraform would be an aclkeeper of these groups). I'll opensource it when it's ready (as we've done with the ansible wrapper).
Now about your issue, do you have an exact list of steps to reproduce? I've tried creating two accounts with --uid-auto, deleting the first one, then creating a third one with --uid-auto, I can't seem to stumble upon it.
On your screenshots, it would imply that the "test" account no longer exists, but its primary group (also named "test") is still there, as if the account deletion process had been interrupted; but that's just what I'm trying to infer based on your screenshots.
To get more info, you might want to try running the
/opt/bastion/bin/admin/check-consistency.plas root on the bastion server, it doesn't modify anything, just checks several things around the accounts and groups and reports inconsistencies when there are.@ogirardot commented on GitHub (Mar 8, 2023):
Hi @speed47 (I'm working with @Pierrelefort ), I've sent you an email related to this ongoing work which is going to be open source as well, we've focused first on users, groups and server ips if you'd like to sync up, it seems we'd both benefit to join forces.
@speed47 commented on GitHub (Mar 14, 2023):
Hey @ogirardot , just replied to your email, I missed it originally!
@Pierrelefort commented on GitHub (Mar 20, 2023):
We are close to open the repository to the public! And in our case we went with an admin account for his impersonate method (adminSudo) to remove/add ingress keys to user.
It happened when we try to create two users the option --uid-auto on parallel calls. When terraform want to create resources (here missing users), he create them on parallel. When we debug the issue, we found out thebastion return the same uid on those parallel calls. Since we cannot change terraform comportement easily we decided to avoid
--uid-autooption.I managed to reproduce the error with log:
This log is quite verbose but you can see with :
ERR_USERADD_FAILED / msg: Error while running useradd for test1 UID/GID 9997 (Command exited with status 4)Creating group test2 with GID 9997... ~ Creating user test2 with UID 9997...That they are created with the same uid/gid.
Then i have done the following commands on my bastion server:
Hope that will help you understand the issue !
We got the following response from the bastion server:
@speed47 commented on GitHub (Mar 21, 2023):
Okay, so this is clearly a race condition when two creations happen exactly at the same time.
The
--uid-autooption doesn't pick a random UID, it picks the highest-still-available one. This is to avoid "stealing" a lower UID that you might need later. This is because, in our use case, we have specific UIDs for humans (the same UID across all the infrastructures), but don't have those for M2M/automation accounts, and we use--uid-autoon those.I can add a mutex there to avoid two simultaneous creations from picking the same UID. Thanks for the detailed report! 👍 . I'll have a branch for you to test with Terraform, using
--uid-auto.@speed47 commented on GitHub (Mar 21, 2023):
Could you try the branch of PR #377 ?
@Pierrelefort commented on GitHub (Mar 22, 2023):
I try the branch of PR with the same operations i did for the log and it work fine !