Re: Allow cluster owner to bypass authentication - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allow cluster owner to bypass authentication
Date
Msg-id 12257.1577469544@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allow cluster owner to bypass authentication  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Allow cluster owner to bypass authentication  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Why not have a special user that can be used for Type: local pg_hba.conf
> lines?  So you'd have:
> local all localowner peer
> That way you're:
> a) only keeping the types we have today
> b) using peer auth, which is what this actually is
> c) NOT using 'trust', which we shouldn't because it's bad
> d) matching up to what Debian has been doing for decades already

But ... if "peer" auth allowed all the cases Peter wants to allow,
we'd not be having this discussion in the first place, would we?

The specific case of concern here is the database's OS-owner wanting
to connect as some other database role than her OS user name.
"peer" doesn't allow that, at least not without messy additional
configuration in the form of a username map.

While the syntax you suggest above could be made to implement that,
it doesn't seem very intuitive to me.  Maybe what we want is some
additional option that acts like a prefab username map:

local all all peer let_OS_owner_in_as_any_role

Bikeshedding the actual option name is left for the reader.  We'd
also have to think whether a regular "map" option can be allowed
on the same line, and if so how the two would interact.  (It might
be as easy as "allow connection if either option allows it".)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [PATCH v1] pg_ls_tmpdir to show directories
Next
From: Tom Lane
Date:
Subject: Re: Allow cluster owner to bypass authentication