pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: Dave Page <dpage@pgadmin.org>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Monitoring roles patch
Date: Tue, 28 Mar 2017 16:17:12 -0400
Message-ID: <24603.1490732232@sss.pgh.pa.us> (raw)
In-Reply-To: <248F178D-0A7F-4C6E-963C-BDEFB295CB67@gmail.com>
References: <CA+OCxoyRdsc1xyLfF9s698gUGyPXBs4CvJ+0Gwo8U65NmYJ7pw@mail.gmail.com>
	<CA+TgmobveXzVPytFOO3AkmsM+Y=YEG+UXcCvgwAt+SgYj85OCA@mail.gmail.com>
	<CA+OCxox9c9-1=bXxA6-gr-iWZbD5zdHYMz=cpC034RKB7zX40Q@mail.gmail.com>
	<CA+TgmoZ5zs50mEzALJqp3qBMC+CdT0ccnjvNJt1Ojiu9rz35zw@mail.gmail.com>
	<20170322131510.GC9812@tamriel.snowman.net>
	<CA+OCxoyt9OMWaK=g2sL8qCTcwrS-8j3=06AZLzXQZ61sUn7gtA@mail.gmail.com>
	<CA+OCxozGTGd-x+cx03N=KJVK=soJwOpTWkq_=zac3P04aBCU4Q@mail.gmail.com>
	<20170323122335.GK9812@tamriel.snowman.net>
	<CA+OCxozZxJouNjY4+-heYSUk=qagoytQXnSjMyO5-R_a_mddKA@mail.gmail.com>
	<c1d3db24-85f0-96bb-0ec3-aeddd9d35941@2ndquadrant.com>
	<CA+OCxox8HW6obNKY5atVA6pX=Z=wQw6rTGcggy4N05k=mLkaAQ@mail.gmail.com>
	<FEE8D3A7-FDBF-432F-BEEF-F28B7D3AD2F4@gmail.com>
	<CA+OCxoy7rqEZ65byS+3E_0dsTKYD8NcUzQB1SiGknARmbxBTDg@mail.gmail.com>
	<957FCA21-99DA-4477-9A6E-C86ACAC23E36@gmail.com>
	<7161672F-1EC5-478F-B307-FF28B01D0D62@gmail.com>
	<19369.1490727172@sss.pgh.pa.us>
	<248F178D-0A7F-4C6E-963C-BDEFB295! CB67@gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Mark Dilger <hornschnorter@gmail.com> writes:
> I don't see anything wrong with adding roles in pg_authid.h with a #define'd
> Oid.  That's actually pretty helpful for anyone writing code against the database,
> as they don't have to look up the Oid of the role.

> But why not then grant privileges to that role in information_schema.sql? 

To the extent that the desired privileges can be represented at the SQL
level, I agree that that's a better solution than hard-wiring checks in C
code.  The problem comes in with cases where that's not fine-grained
enough.  Consider a policy like "anybody can select from pg_stat_activity,
but unless you have privilege X, the query column should read as nulls
except for sessions belonging to you".  That behavior can't realistically
be represented as a separate SQL privilege.  Right now we have "privilege
X" for this purpose hard-coded as "is superuser", but it would be much
better if it were associated with a grantable role.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (61+ messages)  latest in thread

Message-ID: <24603.1490732232@sss.pgh.pa.us>
Permalink:  ../24603.1490732232@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/24603.1490732232@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, hornschnorter@gmail.com, dpage@pgadmin.org, peter.eisentraut@2ndquadrant.com, sfrost@snowman.net, robertmhaas@gmail.com
  Subject: Re: Monitoring roles patch
  In-Reply-To: <24603.1490732232@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox