On Sat, Jan 21, 2023 at 5:11 PM Andres Freund <andres@anarazel.de> wrote:
> > + /* For all these parameters, the value is a local filename. */
> > + if (strcmp(opt->keyword, "passfile") == 0 ||
> > + strcmp(opt->keyword, "sslcert") == 0 ||
> > + strcmp(opt->keyword, "sslkey") == 0 ||
> > + strcmp(opt->keyword, "sslrootcert") == 0 ||
> > + strcmp(opt->keyword, "sslcrl") == 0 ||
> > + strcmp(opt->keyword, "sslcrldir") == 0 ||
> > + strcmp(opt->keyword, "service") == 0)
> > + {
> > + result = true;
> > + break;
> > + }
>
> Do we need to think about 'options' allowing anything bad? I don't
> immediately* see a problem, but ...
If it is, it'd be a different kind of bad. What these parameters all
have in common is that they allow you to read some local file and
maybe benefit from that during the authentication process. options
doesn't let you to do anything like that, and by definition kind of
can't, because it's just a string to be sent to the remote server. As
I noted in my other responses, the local superuser could want to
impose any arbitrary restriction the connection strings users can
choose, and so it's just as plausible that they want to restrict
options as anything else; but this test is about something more
specific.
> > + /*
> > + * For the host parameter, the value might be a local filename.
> > + * It might also be a reference to the local host's abstract UNIX
> > + * socket namespace, which we consider equivalent to a local pathname
> > + * for security purporses.
> > + */
> > + if (strcmp(opt->keyword, "host") == 0 && is_unixsock_path(opt->val))
> > + {
> > + result = true;
> > + break;
> > + }
> > + }
>
> Hm, what about kerberos / gss / SSPI? Aren't those essentially also tied to
> the local filesystem / user?
Uh, I don't know. It doesn't seem so directly true as in these cases,
but what's your thought?
--
Robert Haas
EDB: http://www.enterprisedb.com
