Permissions on tables vs SPL
Posted in 2007
Topics: Stored Procedures & SPL, Security, Permissions & Auditing
I'm look for thoughts here on if this should be considered correct. We grant permissions on tables to users as far as who is allowed to update tables where we have 2 basic groups those who can and those who cannot. We are not using roles as of yet but will when we update to release 10 in a few months. We have a user who is not allowed to update a table and when they attempt to the get an error back and all is well. A new application is written using a cal to a Stored Procedure that updates the same table and this user now has no problem updating the table even though they don't have table permissions to do this. The way to stop this from occurring is to Revoke execute on the SPL from Public and then add it for each user. The few people I have talked to had agreed with me that the table permissions for a user should still be honored, what are some other thoughts?? *** Please note the new address and phone number below. Bruce Simms Data Base Services TALX Corporation 2330 Ball St. Louis, MO 63146 Phone (314) 214-7703 FAX (314) 983-3238 bsimms@talx.com
You´re right, if a user have permission to run a SPL, every comand within the SPL will run whether you run de SPL, even if the user don't have permission directly in a specific table or view. Celso Coimbra -----Mensagem original----- De: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org]Em nome de Bruce Simms Enviada em: sexta-feira, 2 de fevereiro de 2007 11:58 Para: ids@iiug.org Assunto: Permissions on tables vs SPL [8335] I'm look for thoughts here on if this should be considered correct. We grant permissions on tables to users as far as who is allowed to update tables where we have 2 basic groups those who can and those who cannot. We are not using roles as of yet but will when we update to release 10 in a few months. We have a user who is not allowed to update a table and when they attempt to the get an error back and all is well. A new application is written using a cal to a Stored Procedure that updates the same table and this user now has no problem updating the table even though they don't have table permissions to do this. The way to stop this from occurring is to Revoke execute on the SPL from Public and then add it for each user. The few people I have talked to had agreed with me that the table permissions for a user should still be honored, what are some other thoughts?? *** Please note the new address and phone number below. Bruce Simms Data Base Services TALX Corporation 2330 Ball St. Louis, MO 63146 Phone (314) 214-7703 FAX (314) 983-3238 bsimms@talx.com ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Bruce, I have had a like problem. My solution is to make a call in the begining of each SPL to another SPL that checks the permissions and thus sets it locally to the SPL. Who owns what and what they can do varies in different databases, so I have found working in pretty much all of them Informix included, is to manage the permissions with a function that is at the top of all procedures that returns a permission state. I add it to the begining of each SPL just like the version and release comments in a standard template. This way you can control both horizonal and vertical access. This also solves any problems with database version changes that might affect permissions. ________________________________________________________________________________ ____ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091