-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strip empty strings from database revocation stmts #5955
Conversation
It's technically valid to give empty strings as statements to run on most databases. However, in the case of revocation statements, it's not only generally inadvisable but can lead to lack of revocations when you expect them. This strips empty strings from the array of revocation statements. It also makes two other changes: * Return statements on read as empty but valid arrays rather than nulls, so that typing information is inferred (this is more in line with the rest of Vault these days) * Changes field data for TypeStringSlice and TypeCommaStringSlice such that a client-supplied value of `""` doesn't turn into `[]string{""}` but rather `[]string{}`. The latter and the explicit revocation statement changes are related, and defense in depth.
@@ -159,6 +160,8 @@ func (b *databaseBackend) Role(ctx context.Context, s logical.Storage, roleName | |||
result.Statements = stmts | |||
} | |||
|
|||
result.Statements.Revocation = strutil.RemoveEmpty(result.Statements.Revocation) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to move this to below the compatibility helper call below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I specifically didn't as I figured the compatibility helper will then operate on valid data. Do you think that's the wrong approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, i think it's fine here. I just looked and the compatability helper will not set an empty string into the array.
if len(revStmts) > 0 { | ||
role.Statements.Revocation = revStmts | ||
} | ||
role.Statements.Revocation = revocationStmtsRaw.([]string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should you still run remove empty on this value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will still be run below.
* Strip empty strings from database revocation stmts It's technically valid to give empty strings as statements to run on most databases. However, in the case of revocation statements, it's not only generally inadvisable but can lead to lack of revocations when you expect them. This strips empty strings from the array of revocation statements. It also makes two other changes: * Return statements on read as empty but valid arrays rather than nulls, so that typing information is inferred (this is more in line with the rest of Vault these days) * Changes field data for TypeStringSlice and TypeCommaStringSlice such that a client-supplied value of `""` doesn't turn into `[]string{""}` but rather `[]string{}`. The latter and the explicit revocation statement changes are related, and defense in depth.
It's technically valid to give empty strings as statements to run on
most databases. However, in the case of revocation statements, it's not
only generally inadvisable but can lead to lack of revocations when you
expect them. This strips empty strings from the array of revocation
statements.
It also makes two other changes:
Return statements on read as empty but valid arrays rather than nulls,
so that typing information is inferred (this is more in line with the
rest of Vault these days)
Changes field data for TypeStringSlice and TypeCommaStringSlice such
that a client-supplied value of
""
doesn't turn into[]string{""}
but rather
[]string{}
.The latter and the explicit revocation statement changes are related,
and defense in depth.