Thread: 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