> > I am not sure whether the feature does not actually present a security
> > hole ? Two collaborating users can pass each other their privileges.
>
> I don't see any (new) security risk here. Code written by one user can
> be executed with the privileges of another --- so what? That's the
>
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Without making the "definer" need an additional grant for creating such
> a function, it would be like giving him all the privs he has
> "with grant option".
Hmm ... interesting analogy, but does it hold water? The GRANT OPTION
stuff implie
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> I am not sure whether the feature does not actually present a security
> hole ? Two collaborating users can pass each other their privileges.
I don't see any (new) security risk here. Code written by one user can
be executed with the privile
> > Anybody else want to object to this abbreviation idea ?
>
> I thought we already agreed to change the names per Peter's suggestion.
>
> I didn't like the original names whether abbreviated or not ...
Good. I have not seen that agreement, maybe it was implied.
I am not sure whether the feat
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Anybody else want to object to this abbreviation idea ?
I thought we already agreed to change the names per Peter's suggestion.
I didn't like the original names whether abbreviated or not ...
regards, tom lane
--
Actually, I liked the SET AUTHORIZATION { DEFINER | INVOKER } terminology
mentioned earlier.
Mark
Zeugswetter Andreas SB wrote:
>
> > > This patch will implement the "ENABLE PRIVILEGE" and "DISABLE PRIVILEGE"
> > > commands in PL/pgSQL, which, respectively, change the effective uid to that
>
> > This patch will implement the "ENABLE PRIVILEGE" and "DISABLE PRIVILEGE"
> > commands in PL/pgSQL, which, respectively, change the effective uid to that
> > of the function owner and back. It doesn't break security (I hope). The
> > commands can be abbreviated as "ENABLE" and "DISABLE" for
