You are right; I have forgotten to create a "trusted" language.
Mark
Tom Lane wrote:
>
> Mark Volpe <[EMAIL PROTECTED]> writes:
> > ERROR: Only users with Postgres superuser privilege are permitted to create a
> > function in the 'plpgsql' language.
>
> > D'oh! So, if this is the case, then t
Mark Volpe <[EMAIL PROTECTED]> writes:
> ERROR: Only users with Postgres superuser privilege are permitted to create a
> function in the 'plpgsql' language.
> D'oh! So, if this is the case, then the last patch should be fine after all.
No, evidently you broke something, or your plpgsql is insta
OK, I finally got around to adding the superuser check to my patch. So I try
to test it and...
ERROR: Only users with Postgres superuser privilege are permitted to create a
function in the 'plpgsql' language.
D'oh! So, if this is the case, then the last patch should be fine after all.
Mark
Pe
> Mark Volpe writes:
>
> > Good point. Would the issue be resolved by either:
> >
> > - Only allowing the database superuser to use this mechanism?
>
> If you mean "only allow a superuser do define functions using this
> mechanism", that could work. But it would probably make this feature a
> l
Mark Volpe writes:
> Good point. Would the issue be resolved by either:
>
> - Only allowing the database superuser to use this mechanism?
If you mean "only allow a superuser do define functions using this
mechanism", that could work. But it would probably make this feature a
lot less attractive
Good point. Would the issue be resolved by either:
- Only allowing the database superuser to use this mechanism?
- Allowing it only in trigger functions? (That way a user has to actually own
one of the tables)
Mark
Peter Eisentraut wrote:
>
> Bruce Momjian writes:
>
> > > Peter might be refer
Bruce Momjian writes:
> > Peter might be referring to this:
> >
> > http://fts.postgresql.org/db/mw/msg.html?mid=1022775
> >
> > There was some discussion afterward, but I don't think a definite conclusion
> > was reached.
>
> But I see Tom Lane saying he doesn't see a security issue:
>
> h
I updated the patch to use the SET AUTHORIZATION { INVOKER | DEFINER }
terminology. Also, the function owner is now determined and saved at compile
time (no gotchas here, right?). It is located at
http://volpe.home.mindspring.com/pgsql/set_auth.patch
Mark
---(end of broa
> > 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
At 20:47 23/06/01 -0400, Tom Lane wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> The term for user identity is "authorization", so I would
>> call these commands
>
>> SET AUTHORIZATION { INVOKER | DEFINER }
>
>I like that better, too.
>
I have not read the whole thread, but I am used t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The term for user identity is "authorization", so I would
> call these commands
> SET AUTHORIZATION { INVOKER | DEFINER }
I like that better, too.
Overall, the only objection I can see to doing things this way is that
we have to do it over again
Sorry, I have decided not to follow the SQL standard ;-) PRIVILEGE is spelled
correctly in my patch.
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 br
18 matches
Mail list logo
