Subject | Re: [firebird-support] Anonymous access to database |
---|---|
Author | Helen Borrie |
Post date | 2008-04-14T00:35:18Z |
At 03:46 AM 14/04/2008, you wrote:
SQL privileges apply to a specific database.
GRANT ALL ON THIS_OBJECT TO PUBLIC
will give SELECT, UPDATE, INSERT, DELETE and REFERENCES right to all users.
Note,
-- ALL doesn't include EXECUTE privileges for stored procedures. You will have to do a specific
GRANT EXECUTE ON PROCEDURE Procname TO PUBLIC for each stored procedure.
-- REFERENCES allows the user to access the parent of a FOREIGN KEY relationship but it doesn't give SELECT, UPDATE, INSERT or REFERENCES privileges on the parent object.
-- you can't use REVOKE to take away individual privileges that were granted on ALL, nor to override PUBLIC rights for an individual user
If this is for a coursework project, I recommend checking with your tutor whether presenting such an insecure project for a database assignment is likely to incur a penalty on your grade! ;-)
./heLen
>Hi,Databases are not subject to user authentication - that occurs at server level. So, even if you give everyone the same user name and password, they will still be needed in order for the application to connect to the server. You could hard-code them into your application's connection routine...horrible, but doable.
>
>is it possible to allow applications an anonymous access to a database
>on my server? In other words I'd like to disable the user
>authentication of that database so you can connect without the need of
>entering a username and password.
SQL privileges apply to a specific database.
>Or maybe a possibility to grant rights to anyone.That's available "out of the box" - there is an internally defined user in every database called PUBLIC, to which you can grant access rights:
GRANT ALL ON THIS_OBJECT TO PUBLIC
will give SELECT, UPDATE, INSERT, DELETE and REFERENCES right to all users.
Note,
-- ALL doesn't include EXECUTE privileges for stored procedures. You will have to do a specific
GRANT EXECUTE ON PROCEDURE Procname TO PUBLIC for each stored procedure.
-- REFERENCES allows the user to access the parent of a FOREIGN KEY relationship but it doesn't give SELECT, UPDATE, INSERT or REFERENCES privileges on the parent object.
-- you can't use REVOKE to take away individual privileges that were granted on ALL, nor to override PUBLIC rights for an individual user
If this is for a coursework project, I recommend checking with your tutor whether presenting such an insecure project for a database assignment is likely to incur a penalty on your grade! ;-)
./heLen