Improving PostgreSQL Support #1687
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Changing database migrations to occur in sequence instead of all at once for more accurate error reporting in the log Changing HostUUID in the models.Host struct to be unique to fix a constraint issue Changing models.HttpC2Header to contain pointers to ServerConfigIDs and ImplantConfigIDs so that NULL values can be inserted into the database when a type of config does not apply.
Changing implant generation without an associated profile to insert NULL into the database instead of the zero GUID
moloch--
approved these changes
May 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses #1605 and improves PostgreSQL support in Sliver.
It seems that SQLite and PostgreSQL handle the zero GUID differently, so for PostgreSQL databases, we need to store
NULLinstead of the zero GUID. SQLite takes care of storing the zero GUID whenNULLis provided as the value for a UUID column. For PostgreSQL and the current model, we need to be explicit, so some UUIDs have been changed to*uuid.UUIDto signal to GORM that when we pass in anilUUID, we wantNULLand notuuid.Nil(the zero GUID).I tested this change with both SQLite and PostgreSQL (14.11), and they handled the following tasks just fine:
httpimplant without an associated profile as described in Postgres FK constraint errors with fresh install #1605httpimplant with an associated profile and deleting the profileThere may be other tasks which generate errors in PostgreSQL that I am not aware of, but I wanted to hit common use cases. Are there any other common tasks that I should test?
I tested database support in MySQL (8.0) and MariaDB (10.11), and I suggest we remove support for the
mysqldialect. It is not compatible with our database model. MySQL does not have auuiddatatype and instead usesBINARY(16). We could either shift our current model to useBINARY(16)for all dialects or create hooks that translateuuid.UUIDtoBINARY(16)whenmysqlis the active dialect. MariaDB 10.7 gained the UUID datatype, but lacks support for array type which breaks thecrackstationmodel. No one has asked for MySQL or MariaDB support publicly, so I am not sure the juice is worth the squeeze to support it.