From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, jeremy(at)musicsmith(dot)net, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute" |
Date: | 2022-02-11 22:05:20 |
Message-ID: | 2188505.1644617120@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bryn Llewellyn <bryn(at)yugabyte(dot)com> writes:
> I confess that I'm surprised by the choice of the default behavior. It seems to be at odds with the principle of least privilege that insists that you actively opt in to any relevant privilege.
I'd be the first to agree that this behavior sacrifices security
principles for convenience. However, it's not that big a deal
in practice, because functions that aren't SECURITY DEFINER can't
do anything that the caller couldn't do anyway. You do need to
be careful about the default PUBLIC grant if you're making a
SECURITY DEFINER function, but that's a minority use-case.
(I wonder if it'd be practical or useful to emit a warning when
granting permissions on an object that already has a grant of
the same permissions to PUBLIC. That would at least cue people
who don't understand about this behavior that they ought to look
more closely.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-02-11 22:38:50 | Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute" |
Previous Message | Bryn Llewellyn | 2022-02-11 21:44:23 | Re: "grant usage on schema" confers the ability to execute all user-defined functions in that schema, with needing to grant "execute" |