-
Notifications
You must be signed in to change notification settings - Fork 607
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
Ensure required LDAP HBA options are present #4140
Conversation
Issue: PGO-2263
// https://git.postgresql.org/gitweb/?p=postgresql.git;hb=refs/tags/REL_10_0;f=src/backend/libpq/hba.c#l1501 | ||
// https://git.postgresql.org/gitweb/?p=postgresql.git;hb=refs/tags/REL_17_0;f=src/backend/libpq/hba.c#l1886 | ||
// +kubebuilder:validation:XValidation:rule=`has(self.hba) || self.method != "ldap" || (has(self.options) && ["ldapbasedn","ldapprefix","ldapsuffix"].exists(k, k in self.options))`,message=`the "ldap" method requires an "ldapbasedn", "ldapprefix", or "ldapsuffix" option` | ||
// +kubebuilder:validation:XValidation:rule=`has(self.hba) || self.method != "ldap" || !has(self.options) || [["ldapprefix","ldapsuffix"], ["ldapbasedn","ldapbinddn","ldapbindpasswd","ldapsearchattribute","ldapsearchfilter"]].exists_one(a, a.exists(k, k in self.options))`,message=`cannot use "ldapbasedn", "ldapbinddn", "ldapbindpasswd", "ldapsearchattribute", or "ldapsearchfilter" options with "ldapprefix" or "ldapsuffix" options` |
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'm not liking these all-on-one-long-line markers these days.
rule: has(self.hba) || (has(self.connection) && has(self.method)) | ||
- message: the "ldap" method requires an "ldapbasedn", "ldapprefix", | ||
or "ldapsuffix" option | ||
rule: has(self.hba) || self.method != "ldap" || (has(self.options) |
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.
Do I understand this to say that either we have hba or we have ldap with ldap_ options? Is this another way to say that?
rule: has(self.hba) || self.method != "ldap" || (has(self.options) | |
rule: has(self.hba) || self.method == "ldap" && (has(self.options) |
The "A or not B or C (required by B)" feels a little harder to read for me, but am I missing something?
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.
Every rule must evaluate to true. self.method == "ldap"
rejects all other methods.
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 read these as "valid when (1) has hba or (2) isn't ldap or (3) [ldap stuff]"
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.
we have hba or we have ldap with ldap options
Nope. This is saying:
when [we don't have hba] and [the method is ldap],
then [options must be] and [options must blah blah];
otherwise [ok]
But that ☝🏻 "otherwise" is not intended to be "otherwise [the whole thing]." So, it's spelled:
when [we have hba] or [the method isn't ldap], then [ok];
otherwise, [options must be] and [options must blah blah].
Checklist:
Type of Changes:
What is the current behavior (link to any open issues here)?
Postgres requires a few options on LDAP HBA rules. You can forget to add one and not realize until reading logs.
What is the new behavior (if this is a feature change)?
Validation rules ensure that required options are present.
Other Information:
Issue: PGO-2263