Hello,
i searched around about privileges for functions, but it seems,
that there is nothing available in the 7.2.x series.
So my question: Is it possible to execute a function (in this case
a C function) with permissions of the function creater instead
of the user who's actual using function?
At 13:28 24/06/01 +0200, Peter Eisentraut wrote:
>
>If someone wants to implement them, be my guest. I originally needed them
>for fixing the RI permission problems, but they couldn't be used for that
>after all.
>
They were part of a larger permissions overhaul that Jan proposed - IIRC,
at the
As a matter of interest, whatever happened to Perter's & Jan's plans for
setuid functions?
>From memory, Jan's proposal was shelved in favour of something Peter had
previously proposed, is that right?
Philip Warner
On Thu, Jun 21, 2001 at 09:44:43AM +0800, Christopher Kings-Lynne wrote:
> > Okay, what I'm thinking is to have a pair of commands added to
> > PL/pgSQL. For
> > the sake of example we'll call them:
> >
> > ENABLE PRIVLEDGE --> Sets user ID to that of the function's owner
> > DISABLE PRIVLEDGE
Okay, what I'm thinking is to have a pair of commands added to PL/pgSQL. For
the sake of example we'll call them:
ENABLE PRIVLEDGE --> Sets user ID to that of the function's owner
DISABLE PRIVLEDGE --> Restores the original UID
I saw something like this being used in the referential integrity c
I know this topic was discussed a few months ago, but I'm wondering if any
decisions have been reached on if, how, and when setuid functions and triggers
might be implemented. If not, I have an idea to throw at it.
Thanks,
Mark
---(end of broadcast)---
> > Since you can write extensions to PostgreSQL that reach far into the OS,
> > it does make sense to execute those extensions under a "non priviledged"
> > user, and not postgres.
>
> Agreed.
>
> > This OS user would somehow be tied to the username that the client
> > passes as his credential
Zeugswetter Andreas SB writes:
> Since you can write extensions to PostgreSQL that reach far into the OS,
> it does make sense to execute those extensions under a "non priviledged"
> user, and not postgres.
Agreed.
> This OS user would somehow be tied to the username that the client
> passes as
> But the pg_shadow authentication is based on credentials
> provided by the
> client whereas what you propose here would run on the server, so this
> doesn't make sense.
Since you can write extensions to PostgreSQL that reach far into the OS,
it does make sense to execute those extensions und
Zeugswetter Andreas SB writes:
> Imho it is fine to get rid of the usesysid in our internal
> authorization system, but we should not get rid of the only field that
> can tie a db user to an os user. Imho we should not do a "by name"
> lookup and eliminate the field.
Um, well, the only possible
10 matches
Mail list logo
