Thread: default privileges wording
I was just reading the docs on default privileges, and they say this: Depending on the type of object, the initial default privileges might include granting some privileges to PUBLIC. Thedefault is no public access for tables, columns, schemas, and tablespaces; CONNECT privilege and TEMP table creationprivilege for databases; EXECUTE privilege for functions; and USAGE privilege for languages. The object ownercan of course revoke these privileges. I had to read it several times before I understood it properly, so I'm not terribly happy with it. I'm thinking of revising it slightly like this: Depending on the type of object, the initial default privileges might include granting some privileges to PUBLIC, includingCONNECT privilege and TEMP table creation privilege for databases, EXECUTE privilege for functions, and USAGEprivilege for languages. For tables, columns, schemas and tablespaces the default is no public access. The objectowner can of course revoke any default PUBLIC privileges. That seems clearer to me, but maybe other people can make it clearer still. Comments? cheers andrew
Excerpts from Andrew Dunstan's message of mié jun 29 11:21:12 -0400 2011: > > I was just reading the docs on default privileges, and they say this: > > Depending on the type of object, the initial default privileges > might include granting some privileges to PUBLIC. The default is no > public access for tables, columns, schemas, and tablespaces; CONNECT > privilege and TEMP table creation privilege for databases; EXECUTE > privilege for functions; and USAGE privilege for languages. The > object owner can of course revoke these privileges. > > > I had to read it several times before I understood it properly, so I'm > not terribly happy with it. I'm thinking of revising it slightly like this: > > Depending on the type of object, the initial default privileges > might include granting some privileges to PUBLIC, including CONNECT > privilege and TEMP table creation privilege for databases, EXECUTE > privilege for functions, and USAGE privilege for languages. For > tables, columns, schemas and tablespaces the default is no public > access. The object owner can of course revoke any default PUBLIC > privileges. Some types of objects [have/include/grant] no privileges to PUBLIC by default. These are tables, columns, schemas and tablespaces. For other types, the default privileges granted to PUBLIC are as follows: CONNECT privilege and TEMP table creation privilege for databases; EXECUTE privilege for functions; and USAGE privilege for languages. The object owner can, of course, revoke [these/any default] privileges. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Jun 29, 2011 at 11:50:38AM -0400, Alvaro Herrera wrote: > Excerpts from Andrew Dunstan's message of mié jun 29 11:21:12 -0400 2011: > > > > I was just reading the docs on default privileges, and they say this: > > > > Depending on the type of object, the initial default privileges > > might include granting some privileges to PUBLIC. The default is no > > public access for tables, columns, schemas, and tablespaces; CONNECT > > privilege and TEMP table creation privilege for databases; EXECUTE > > privilege for functions; and USAGE privilege for languages. The > > object owner can of course revoke these privileges. > > > > > > I had to read it several times before I understood it properly, so I'm > > not terribly happy with it. I'm thinking of revising it slightly like this: > > > > Depending on the type of object, the initial default privileges > > might include granting some privileges to PUBLIC, including CONNECT > > privilege and TEMP table creation privilege for databases, EXECUTE > > privilege for functions, and USAGE privilege for languages. For > > tables, columns, schemas and tablespaces the default is no public > > access. The object owner can of course revoke any default PUBLIC > > privileges. > > Some types of objects [have/include/grant] no privileges to PUBLIC by > default. These are tables, columns, schemas and tablespaces. For other > types, the default privileges granted to PUBLIC are as follows: CONNECT > privilege and TEMP table creation privilege for databases; EXECUTE > privilege for functions; and USAGE privilege for languages. The object > owner can, of course, revoke [these/any default] privileges. How about this? Some types of objects deny all privileges to PUBLIC by default. These are tables, columns, schemas and tablespaces. For other types, the default privileges granted to PUBLIC are as follows: CONNECT privilege and TEMP table creation privilege for databases; EXECUTE privilege for functions; and USAGE privilege for languages. The object owner can, of course, revoke both default and expressly granted privileges. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Wed, Jun 29, 2011 at 1:20 PM, David Fetter <david@fetter.org> wrote: > On Wed, Jun 29, 2011 at 11:50:38AM -0400, Alvaro Herrera wrote: >> Excerpts from Andrew Dunstan's message of mié jun 29 11:21:12 -0400 2011: >> > >> > I was just reading the docs on default privileges, and they say this: >> > >> > Depending on the type of object, the initial default privileges >> > might include granting some privileges to PUBLIC. The default is no >> > public access for tables, columns, schemas, and tablespaces; CONNECT >> > privilege and TEMP table creation privilege for databases; EXECUTE >> > privilege for functions; and USAGE privilege for languages. The >> > object owner can of course revoke these privileges. >> > >> > >> > I had to read it several times before I understood it properly, so I'm >> > not terribly happy with it. I'm thinking of revising it slightly like this: >> > >> > Depending on the type of object, the initial default privileges >> > might include granting some privileges to PUBLIC, including CONNECT >> > privilege and TEMP table creation privilege for databases, EXECUTE >> > privilege for functions, and USAGE privilege for languages. For >> > tables, columns, schemas and tablespaces the default is no public >> > access. The object owner can of course revoke any default PUBLIC >> > privileges. >> >> Some types of objects [have/include/grant] no privileges to PUBLIC by >> default. These are tables, columns, schemas and tablespaces. For other >> types, the default privileges granted to PUBLIC are as follows: CONNECT >> privilege and TEMP table creation privilege for databases; EXECUTE >> privilege for functions; and USAGE privilege for languages. The object >> owner can, of course, revoke [these/any default] privileges. > > How about this? > > Some types of objects deny all privileges to PUBLIC by default. These > are tables, columns, schemas and tablespaces. For other types, the > default privileges granted to PUBLIC are as follows: CONNECT privilege > and TEMP table creation privilege for databases; EXECUTE privilege for > functions; and USAGE privilege for languages. The object owner can, > of course, revoke both default and expressly granted privileges. Or, since I find the use of the word "deny" a bit unclear: When a table, column, schema, or tablespace is created, no privileges are granted to PUBLIC. But for other objects, some privileges will be granted to PUBLIC automatically at the time the object is created: CONNECT privilege and TEMP table creation privilege for database, ... <etc., the rest as you have it> -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011: > > How about this? > > > > Some types of objects deny all privileges to PUBLIC by default. These > > are tables, columns, schemas and tablespaces. For other types, the > > default privileges granted to PUBLIC are as follows: CONNECT privilege > > and TEMP table creation privilege for databases; EXECUTE privilege for > > functions; and USAGE privilege for languages. The object owner can, > > of course, revoke both default and expressly granted privileges. > > Or, since I find the use of the word "deny" a bit unclear: > > When a table, column, schema, or tablespace is created, no privileges > are granted to PUBLIC. But for other objects, some privileges will be > granted to PUBLIC automatically at the time the object is created: > CONNECT privilege and TEMP table creation privilege for database, ... > <etc., the rest as you have it> Hmm, I like David's suggestion better, but I agree with you that "deny" isn't the right verb there. I have no better suggestions at moment though. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Jun 29, 2011 at 04:49:15PM -0400, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011: > > > > How about this? > > > > > > Some types of objects deny all privileges to PUBLIC by default. > > > These are tables, columns, schemas and tablespaces. For other > > > types, the default privileges granted to PUBLIC are as follows: > > > CONNECT privilege and TEMP table creation privilege for > > > databases; EXECUTE privilege for functions; and USAGE privilege > > > for languages. The object owner can, of course, revoke both > > > default and expressly granted privileges. > > > > Or, since I find the use of the word "deny" a bit unclear: > > > > When a table, column, schema, or tablespace is created, no > > privileges are granted to PUBLIC. But for other objects, some > > privileges will be granted to PUBLIC automatically at the time the > > object is created: CONNECT privilege and TEMP table creation > > privilege for database, ... <etc., the rest as you have it> > > Hmm, I like David's suggestion better, but I agree with you that > "deny" isn't the right verb there. I have no better suggestions at > moment though. I chose "deny" in the sense of "default deny," which is a term of art in security engineering referring to an access control policy. http://en.wikipedia.org/wiki/Security_engineering#Security_stance Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 06/29/2011 05:16 PM, David Fetter wrote: >> >> Hmm, I like David's suggestion better, but I agree with you that >> "deny" isn't the right verb there. I have no better suggestions at >> moment though. > I chose "deny" in the sense of "default deny," which is a term of art > in security engineering referring to an access control policy. > > http://en.wikipedia.org/wiki/Security_engineering#Security_stance > > If two of our own most deeply invested hackers find it unclear, many other will too, term of art or not. cheers andrew
On Wed, Jun 29, 2011 at 4:49 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011: > >> > How about this? >> > >> > Some types of objects deny all privileges to PUBLIC by default. These >> > are tables, columns, schemas and tablespaces. For other types, the >> > default privileges granted to PUBLIC are as follows: CONNECT privilege >> > and TEMP table creation privilege for databases; EXECUTE privilege for >> > functions; and USAGE privilege for languages. The object owner can, >> > of course, revoke both default and expressly granted privileges. >> >> Or, since I find the use of the word "deny" a bit unclear: >> >> When a table, column, schema, or tablespace is created, no privileges >> are granted to PUBLIC. But for other objects, some privileges will be >> granted to PUBLIC automatically at the time the object is created: >> CONNECT privilege and TEMP table creation privilege for database, ... >> <etc., the rest as you have it> > > Hmm, I like David's suggestion better, but I agree with you that "deny" > isn't the right verb there. I have no better suggestions at moment > though. Well, I think the only relevant verb is "grant", so that's why I was trying to phrase it in terms of the negative of that - i.e. explain that, in this case, we don't grant anything. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Jun 29, 2011 at 08:42:58PM -0400, Robert Haas wrote: > On Wed, Jun 29, 2011 at 4:49 PM, Alvaro Herrera > <alvherre@commandprompt.com> wrote: > > Excerpts from Robert Haas's message of mié jun 29 13:42:34 -0400 2011: > > > >> > How about this? > >> > > >> > Some types of objects deny all privileges to PUBLIC by default. These > >> > are tables, columns, schemas and tablespaces. For other types, the > >> > default privileges granted to PUBLIC are as follows: CONNECT privilege > >> > and TEMP table creation privilege for databases; EXECUTE privilege for > >> > functions; and USAGE privilege for languages. The object owner can, > >> > of course, revoke both default and expressly granted privileges. > >> > >> Or, since I find the use of the word "deny" a bit unclear: > >> > >> When a table, column, schema, or tablespace is created, no privileges > >> are granted to PUBLIC. But for other objects, some privileges will be > >> granted to PUBLIC automatically at the time the object is created: > >> CONNECT privilege and TEMP table creation privilege for database, ... > >> <etc., the rest as you have it> > > > > Hmm, I like David's suggestion better, but I agree with you that "deny" > > isn't the right verb there. I have no better suggestions at moment > > though. > > Well, I think the only relevant verb is "grant", so that's why I was > trying to phrase it in terms of the negative of that - i.e. explain > that, in this case, we don't grant anything. How about this? PostgreSQL grants some types of objects some default privileges to PUBLIC. Tables, columns, schemas and tablespaces grant no privileges to PUBLIC by default. For other types, the default privileges granted to PUBLIC are as follows: CONNECT and CREATE TEMP TABLE for databases; EXECUTE privilege for functions; and USAGE privilege for languages. The object owner can, of course, REVOKE both default and expressly granted privileges. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Wed, Jun 29, 2011 at 8:53 PM, David Fetter <david@fetter.org> wrote: > How about this? > > PostgreSQL grants some types of objects some default privileges to > PUBLIC. Tables, columns, schemas and tablespaces grant no privileges > to PUBLIC by default. For other types, the default privileges granted > to PUBLIC are as follows: CONNECT and CREATE TEMP TABLE for databases; > EXECUTE privilege for functions; and USAGE privilege for languages. > The object owner can, of course, REVOKE both default and expressly > granted privileges. That looks pretty good to me. I'd probably say "grants default privileges on some types of objects" rather than "grants some types of objects default privileges", but YMMV. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 06/29/2011 09:20 PM, Robert Haas wrote: > On Wed, Jun 29, 2011 at 8:53 PM, David Fetter<david@fetter.org> wrote: >> How about this? >> >> PostgreSQL grants some types of objects some default privileges to >> PUBLIC. Tables, columns, schemas and tablespaces grant no privileges >> to PUBLIC by default. For other types, the default privileges granted >> to PUBLIC are as follows: CONNECT and CREATE TEMP TABLE for databases; >> EXECUTE privilege for functions; and USAGE privilege for languages. >> The object owner can, of course, REVOKE both default and expressly >> granted privileges. > That looks pretty good to me. I'd probably say "grants default > privileges on some types of objects" rather than "grants some types of > objects default privileges", but YMMV. Yeah, that sounds good. The second sentence reads oddly to me - it's not the objects that are doing (or not doing) the granting; rather they are the subjects of the (lack of) granted privileges. Maybe we should say: "No privileges are granted to PUBLIC by default on tables, columns, schemas or tablespaces." cheers andrew
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 29, 2011 at 8:53 PM, David Fetter <david@fetter.org> wrote:
>> How about this?
>>
>> PostgreSQL grants some types of objects some default privileges to
>> PUBLIC. �Tables, columns, schemas and tablespaces grant no privileges
>> to PUBLIC by default. �For other types, the default privileges granted
>> to PUBLIC are as follows: CONNECT and CREATE TEMP TABLE for databases;
>> EXECUTE privilege for functions; and USAGE privilege for languages.
>> The object owner can, of course, REVOKE both default and expressly
>> granted privileges.
> That looks pretty good to me. I'd probably say "grants default
> privileges on some types of objects" rather than "grants some types of
> objects default privileges", but YMMV.
Yeah --- this is using "grant" in mutually incompatible ways. We grant
privileges on objects to users, and pointing the verb in the other
direction will just confuse people more. The first sentence in
particular is a mess.
regards, tom lane