Re: 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. 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.

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(at)commandprompt(dot)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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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(at)fetter(dot)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(at)commandprompt(dot)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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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(at)commandprompt(dot)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(at)commandprompt(dot)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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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(at)fetter(dot)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(at)fetter(dot)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(at)gmail(dot)com> writes:
> On Wed, Jun 29, 2011 at 8:53 PM, David Fetter <david(at)fetter(dot)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