Hannu Krosing wrote:
Would SECURITY DEFINER not work for pljava ?
Or if you are looking for something that has to be done inside the pl
handler maybe you should use another function with SECURITY DEFINER and
owned by superuser for function lookups ?
Of course. That's even better then a SetUser. Ful
On R, 2004-12-17 at 21:12, Thomas Hallgren wrote:
> I'd like some views on the following issue.
>
> The pljava function call handler will resolve a class name using a
> loader that in turn uses a specific table in the PostgreSQL database.
> Hence, the caller of the function must have select perm
Tom Lane wrote:
Well, it's not. Exactly what are you going to flip it *to*? You can't
hardwire a particular userid and expect to have a robust solution.
I'd recommend the lower-level approach myself.
How about flipping to the owner of the table, (or perhaps schema since
all pljava specific stuff
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
The Java runtime system just does'nt provide a ClassLoader that can be
made to follow the semantics stipulated by the SQL 2003 Java
mapping.
[ raised eyebrow... ] Can the spec really be that broken? They don't
write these things in a to
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> You can use GetUserId() and SetUserId() to flip the current user
>> identity around as you like. For such a simple query, however, it
>> might seem better to bypass SPI altogether and do a straight table
>> lookup through
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> The Java runtime system just does'nt provide a ClassLoader that can be
> made to follow the semantics stipulated by the SQL 2003 Java
> mapping.
[ raised eyebrow... ] Can the spec really be that broken? They don't
write these things in a total vacuum
Peter Eisentraut wrote:
Thomas Hallgren wrote:
Is there a way to bypass security checks that retains the SQL parser?
I'd like my C-code to do something like:
impersonate pgadmin
SELECT image from class_table
revert to self
You can use GetUserId() and SetUserId() to flip the current user
id
Tom Lane wrote:
AFAICS you are choosing to do things in the hardest possible way, on
the basis of completely unfounded suppositions about performance gains.
I recommend the KISS principle. Leave the jar files as jars and let the
Java runtime system manage them.
If that was an option, believe me
Thomas Hallgren wrote:
> Is there a way to bypass security checks that retains the SQL parser?
> I'd like my C-code to do something like:
>
> impersonate pgadmin
> SELECT image from class_table
> revert to self
You can use GetUserId() and SetUserId() to flip the current user
identity around as yo
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> This is all about access to the java class images, i.e. the actual byte
> codes that make out the Java functions that will execute. Class files
> are normally grouped into archives called jar files (zip format
> essentially) and the SQL 2003 standard
Tom Lane wrote:
Just out of curiosity, why use a table at all, if you intend to forbid
all SQL-level access to it? Seems to me that what you want is either
a table (C array) hard-wired in the code, or a configuration file.
Andrew Dunstan wrote:
> I'm not sure if I understand exactly what you want,
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I don't think a view would help much. I want to completely prevent the
> user from viewing or changing any data stored in the table. Using a view
> would just move the problem. Now the user must have select access to the
> view in order to call the f
Thomas Hallgren wrote:
vamsi,
Why dont you create a view on the table and access the view rather
than the table. I guess this would resolve the issue.
What ever select statement you want to have on the table you can make
it a select statement of the view. thus restricting the access to the
main ta
vamsi,
Why dont you create a view on the table and access the view rather
than the table. I guess this would resolve the issue.
What ever select statement you want to have on the table you can make
it a select statement of the view. thus restricting the access to the
main table.
Looking forward to
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> ... Is there any way to bypass the
> permissions when I do an SPI call from within a call handler somehow?
No, but you don't have to use SPI. C code can do pretty much what it
wants to.
regards, tom lane
Hi Thomas,
Why dont you create a view on the table and access the view rather
than the table. I guess this would resolve the issue.
What ever select statement you want to have on the table you can make
it a select statement of the view. thus restricting the access to the
main table.
Looking forw
I'd like some views on the following issue.
The pljava function call handler will resolve a class name using a
loader that in turn uses a specific table in the PostgreSQL database.
Hence, the caller of the function must have select permissions on that
table or the function will fail. I would lik
17 matches
Mail list logo
