| Author |
Topic |
|
harshal_in
Aged Yak Warrior
633 Posts |
Posted - 2003-01-03 : 02:20:46
|
| hi,I want to grant select ,update delete on all the tables and execute permissions to all the stored procedures in my database to the role public.Can I grant these permissions to the public role in model database so that these permissions are remain when ever I create a new database?and is it possible to grant permissions on the objects before creating them? I mean that I have to grant permissions to all the objects in the database ,so when ever I create a new object I have to explicitly grant permissions to the users instead if it is possible to grant the permissions once for all the objects by granting them in model database so that it inherits in all the new databases?any thoughts?regards,harshal.Expect the UnExpected |
|
|
Wanderer
Master Smack Fu Yak Hacker
1168 Posts |
Posted - 2003-01-03 : 03:23:41
|
| Well, the easiest way to meet all the requirements would be to have the users alias to dbo. DBO will have all the right's you want, here. Unfortunately, it seems that you can't add an alias a role.Alternatively, how about creating an account LIKE guest (don't use guest, since it is a default, and anyone can try and hack it), and adding the new "guest2" userid to db_owner role ?HTH*#* *#* *#* *#* Chaos, Disorder and Panic ... my work is done here! |
 |
|
|
harshal_in
Aged Yak Warrior
633 Posts |
Posted - 2003-01-03 : 06:03:51
|
quote: Well, the easiest way to meet all the requirements would be to have the users alias to dbo. DBO will have all the right's you want, here. Unfortunately, it seems that you can't add an alias a role.Alternatively, how about creating an account LIKE guest (don't use guest, since it is a default, and anyone can try and hack it), and adding the new "guest2" userid to db_owner role ?HTH*#* *#* *#* *#* Chaos, Disorder and Panic ... my work is done here!
ya , but I do not want my users to create new objects in the database will this restrict them from creating new objects?Expect the UnExpected |
 |
|
|
Wanderer
Master Smack Fu Yak Hacker
1168 Posts |
Posted - 2003-01-03 : 06:18:21
|
| Unfortunately it does mean that they would be able to create objects etc.I'll try and see if I can think of another way ...*#* *#* *#* *#* Chaos, Disorder and Panic ... my work is done here! |
 |
|
|
Onamuji
Aged Yak Warrior
504 Posts |
Posted - 2003-01-03 : 08:24:07
|
IF OBJECTPROPERTY(OBJECT_ID(N'GrantPermissions'), N'IsProcedure') = 1 DROP PROCEDURE GrantPermissionsGOCREATE PROCEDURE GrantPermissions (@name NVARCHAR(128)) AS SET NOCOUNT ON DECLARE @executes TABLE (SQL NVARCHAR(4000)) DECLARE @sql NVARCHAR(4000) INSERT INTO @executes (SQL) SELECT 'GRANT SELECT,UPDATE,DELETE ON ' + '[' + TABLE_CATALOG + '].[' + TABLE_SCHEMA + '].[' + TABLE_NAME + '] ' + 'TO [' + @name + ']' FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' INSERT INTO @executes (SQL) SELECT 'GRANT EXECUTE ON ' + '[' + ROUTINE_CATALOG + '].[' + ROUTINE_SCHEMA + '].[' + ROUTINE_NAME + '] ' + 'TO [' + @name + ']' FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_TYPE = 'PROCEDURE' WHILE EXISTS(SELECT * FROM @executes) BEGIN SELECT @sql = SQL FROM @executes EXEC sp_executesql @sql DELETE FROM @executes WHERE SQL = @sql ENDGO |
 |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-01-03 : 12:37:11
|
| I realize that this does not answer your question, but...It seems to me that instead of figuring out how to do this that you should rethink your security strategy. Instead of giving out practically all permissions, just give out the ones that are needed. The way that we do it here is grant execute on all stored procedures. Since all of our sql code is in stored procedures, we then only need to grant table level permissions on those tables that will have dynamic sql going against it. There are a few exceptions to this rule here, but we take a look at each of these exceptions to determine the minimum amount of permissions required. You should never give out the maximum amount of permissions on a database. Always start with the minimum and then add as necessary.Edited by - tduggan on 01/03/2003 12:46:16 |
 |
|
|
Onamuji
Aged Yak Warrior
504 Posts |
Posted - 2003-01-03 : 12:47:09
|
| or never give out to the public role... i reserve the public role for views with select only access... stored procedures get execute permissions on a custom "application" role that application logins map to.... since many of the stored procedures are administrative ones this prevents people that are in the public role (everyone is in the public role by default and this cannot be changed) from executing the stored procedures... |
 |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-01-03 : 12:55:53
|
| Onamuji,That is exactly what we do here too. I was just detailing what the application level userids (all in one role since they all need similar permissions) get for permissions. We also add a role that is similar to public. This role gets the db_datareader role. Users in this role are developers and QA personnel(at least for production). We do not grant any permissions to the public role. |
 |
|
|
harshal_in
Aged Yak Warrior
633 Posts |
Posted - 2003-01-06 : 05:46:13
|
| thankyou everyone that helped a lot.regards,harshal.Expect the UnExpected |
 |
|
|
|