On 4/5/20 6:15 AM, Peter Eisentraut wrote:
On 2020-03-27 15:58, David Steele wrote:
Hi Peter,
On 12/27/19 3:22 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think it'd be great if this behavior could be implemented
within the notation, because we could then just set up a
On 2020-03-27 15:58, David Steele wrote:
Hi Peter,
On 12/27/19 3:22 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think it'd be great if this behavior could be implemented
within the notation, because we could then just set up a
non-empty default pg_ident.conf with useful
Hi Peter,
On 12/27/19 3:22 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think it'd be great if this behavior could be implemented
within the notation, because we could then just set up a
non-empty default pg_ident.conf with useful behavioral
examples in the form of prefab
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Still, I take your point that "peer" does risk letting in a set of
> >> connections wider than what the DBA was thinking about. Enlarging
> >> on my other response that what
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> 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?
>
> > I'm still not entirely convince
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Still, I take your point that "peer" does risk letting in a set of
>> connections wider than what the DBA was thinking about. Enlarging
>> on my other response that what we want is an auth option not a whole
>> new auth type, maybe
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> 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?
> I'm still not entirely convinced it doesn't, but that's also because I
> keep thinking we're t
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > Well, if this is the pg_hba.conf setup and I am considering the
> > authentication method when creating new users, then my only safe option
> > is to not create any new users. Because which OS users exist is not
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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,
Peter Eisentraut writes:
> Well, if this is the pg_hba.conf setup and I am considering the
> authentication method when creating new users, then my only safe option
> is to not create any new users. Because which OS users exist is not
> controlled by the DBA. If the OS admin and the DBA are t
Stephen Frost 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 s
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-12-18 16:24, Stephen Frost wrote:
> >Which represents pretty much exactly what you're going for here, doesn't
> >it..?
>
> This is similar but not exactly the same thing: (1) It doesn't work if the
> OS user name an
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-12-18 15:09, Robert Haas wrote:
> >I feel like this is taking a policy decision that properly belongs in
> >pg_hba.conf and making it into a GUC. If you're introducing a GUC
> >because it's not possible to configure
On 2019-12-18 16:24, Stephen Frost wrote:
As for the question about how to set up pg_hba.conf so that just the DB
owner can log in via peer, the Debian/Ubuntu packages are deployed, by
default, with an explicit message and entry:
# DO NOT DISABLE!
# If you change this first entry you will need t
On 2019-12-18 15:09, Robert Haas wrote:
I feel like this is taking a policy decision that properly belongs in
pg_hba.conf and making it into a GUC. If you're introducing a GUC
because it's not possible to configure the behavior that you want in
pg_hba.conf, then I think the solution to that is to
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-12-17 05:40, Stephen Frost wrote:
> >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >>The idea is that if you connect over a Unix-domain socket and the local
> >>(effective) user is the same as the se
On Tue, Dec 17, 2019 at 5:27 AM Peter Eisentraut
wrote:
> I realize that there are a number of facilities nowadays to do enhanced
> security setups. But let's consider what 99% of users are using. If
> the database server runs as user X and you are logged in as user X, you
> should be able to ma
On 2019-12-17 05:40, Stephen Frost wrote:
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
The idea is that if you connect over a Unix-domain socket and the local
(effective) user is the same as the server's (effective) user, then
access should be granted immediately without any chec
> > This has been hanging around for a while. I guess the reason it hasn't
> > got much attention is that on its own it's not terribly useful.
> > However, when you consider that it's a sensible prelude to setting a
> > more secure default for auth in initdb (I'd strongly advocate
> > SCRAM-SHA-256
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> The idea is that if you connect over a Unix-domain socket and the local
> (effective) user is the same as the server's (effective) user, then
> access should be granted immediately without any checking of
> pg_hba.conf. Bec
On Thu, Aug 15, 2019 at 9:07 PM Peter Eisentraut
wrote:
>
> This is an implementation of the idea I mentioned in [0].
>
> The naming and description perhaps isn't ideal yet but it works in
> principle.
>
> The idea is that if you connect over a Unix-domain socket and the local
> (effective) user i
21 matches
Mail list logo
