Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 granting permissions to role

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!
Go to Top of Page

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
Go to Top of Page

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!
Go to Top of Page

Onamuji
Aged Yak Warrior

504 Posts

Posted - 2003-01-03 : 08:24:07

IF OBJECTPROPERTY(OBJECT_ID(N'GrantPermissions'), N'IsProcedure') = 1
DROP PROCEDURE GrantPermissions
GO

CREATE 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
END
GO


Go to Top of Page

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
Go to Top of Page

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...

Go to Top of Page

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.

Go to Top of Page

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
Go to Top of Page
   

- Advertisement -