Thread: Add sentence about SECURITY LABEL object ownership

Add sentence about SECURITY LABEL object ownership

From
Patrick Stählin
Date:
Hi,

I noticed that we don't document that you need to own the object being 
modified by SECURITY LABEL.

Page: https://www.postgresql.org/docs/current/sql-security-label.html

I've attached a patch that would have answered that question (for me) 
without diving into the code.

Thanks,
Patrick
Attachment

Re: Add sentence about SECURITY LABEL object ownership

From
Laurenz Albe
Date:
On Thu, 2025-06-05 at 15:29 +0200, Patrick Stählin wrote:
> Hi,
>
> I noticed that we don't document that you need to own the object being
> modified by SECURITY LABEL.
>
> Page: https://www.postgresql.org/docs/current/sql-security-label.html
>
> I've attached a patch that would have answered that question (for me)
> without diving into the code.

> --- a/doc/src/sgml/ref/security_label.sgml
> +++ b/doc/src/sgml/ref/security_label.sgml
> @@ -84,6 +84,10 @@ SECURITY LABEL [ FOR <replaceable class="parameter">provider</replaceable> ] ON
>     based on object labels, rather than traditional discretionary access control
>     (DAC) concepts such as users and groups.
>    </para>
> +
> +  <para>
> +   You must own the database object to use the <command>SECURITY LABEL</command>.
> +  </para>
>   </refsect1>
>
>   <refsect1>

Wouldn't it be more accurate to say that you have to be a member of the owning role?
But perhaps that would be complicated enough to confuse many users.

In general, +1 for documenting that.

Yours,
Laurenz Albe



Re: Add sentence about SECURITY LABEL object ownership

From
Patrick Stählin
Date:
On 6/5/25 4:21 PM, Laurenz Albe wrote:
>> +
>> +  <para>
>> +   You must own the database object to use the <command>SECURITY LABEL</command>.
>> +  </para>
>>    </refsect1>
>>   
>>    <refsect1>
> 
> Wouldn't it be more accurate to say that you have to be a member of the owning role?
> But perhaps that would be complicated enough to confuse many users.

We're calling check_object_ownership which errors out with:

    aclcheck_error(ACLCHECK_NOT_OWNER, [...])

which in turn then aborts with "must be owner of [...]". But checking 
the code, we do call has_privs_of_role, so you're absolutely right.

In doc/src/sgml/ref/alter_*.sgml we use the phrase "You must own the 
[...]" to describe the privileges needed. Let me know if you want me to 
change the wording.

While double checking I noticed that other docs don't have the extra 
"the " before "<command>[...] " so I dropped that in my v2 patch.

Thanks for reviewing!
Patrick
Attachment

Re: Add sentence about SECURITY LABEL object ownership

From
Tom Lane
Date:
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Thu, 2025-06-05 at 15:29 +0200, Patrick Stählin wrote:
>> I noticed that we don't document that you need to own the object being
>> modified by SECURITY LABEL.

Yeah, clearly a documentation oversight.

> Wouldn't it be more accurate to say that you have to be a member of the owning role?
> But perhaps that would be complicated enough to confuse many users.
> In general, +1 for documenting that.

Our standard boilerplate for this is, eg,

   You must own the table to use <command>ALTER TABLE</command>.

I don't see a reason to do it differently here.

            regards, tom lane



Re: Add sentence about SECURITY LABEL object ownership

From
Laurenz Albe
Date:
On Thu, 2025-06-05 at 11:19 -0400, Tom Lane wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > On Thu, 2025-06-05 at 15:29 +0200, Patrick Stählin wrote:
> > > I noticed that we don't document that you need to own the object being
> > > modified by SECURITY LABEL.
>
> Yeah, clearly a documentation oversight.
>
> > Wouldn't it be more accurate to say that you have to be a member of the owning role?
> > But perhaps that would be complicated enough to confuse many users.
> > In general, +1 for documenting that.
>
> Our standard boilerplate for this is, eg,
>
>    You must own the table to use <command>ALTER TABLE</command>.
>
> I don't see a reason to do it differently here.

Objection withdrawn.

Yours,
Laurenz Albe