Problem granting usage on language c
When I try to grant usage on language c in 7.3b1 I get an error message
saying I can't because the language isn't trusted. Is this different in b2?
I can see using whether or not a language is trusted to set defaults,
but now that access can be controlled it would be useful to grant
access to load c functions to users that are trusted.
Here is the example:
grant usage on language c to bruno;
ERROR: language "c" is not trusted
On Sun, Oct 20, 2002 at 10:50:59 -0500,
Bruno Wolff III <bruno@wolff.to> wrote:
When I try to grant usage on language c in 7.3b1 I get an error message
saying I can't because the language isn't trusted. Is this different in b2?
I can see using whether or not a language is trusted to set defaults,
but now that access can be controlled it would be useful to grant
access to load c functions to users that are trusted.
Looking at yesterday's CVS suggests that it is intended for untrusted
languages to only be used by superusers.
I would like to run up a trial balloon that the follwoing changes be made:
When creating new languages, untrusted ones default to not granting usage
to public and trusted ones default to granting usage to public. And that
access to languages be controlled by just the usage permission and not
whether a language is trusted or not.
The argument for this is that trusted users may want to work in an environment
where some things are blocked off to prevent shooting one's self in the foot.
So that you might want to be able to create c functions without being able
to do anything.
The risk is that the admins have to realize that granting access to untrusted
languages is giving away the keys to the castle.
Bruno Wolff III <bruno@wolff.to> writes:
When I try to grant usage on language c in 7.3b1 I get an error message
saying I can't because the language isn't trusted. Is this different in b2?
No.
I can see using whether or not a language is trusted to set defaults,
but now that access can be controlled it would be useful to grant
access to load c functions to users that are trusted.
There is no point at all in providing shades of access to untrusted
languages. A user who can define his own C functions is God: he can
use the functions to bypass any security restrictions you may think
you have on him. So it's useless to say that any privilege state
less than superuser-dom is appropriate for creating C functions.
later ...
The risk is that the admins have to realize that granting access to
untrusted languages is giving away the keys to the castle.
Equating it to superuser status seems an effective way of reminding
them of that.
regards, tom lane