I have a custom procedure that basically replaces msdb.dbo.SP_ADDTASK which works fine when using a user with database role permissions, but when I switch to an application_role permissions scheme, the same procedure fails when trying to access xp_sqlagent_is_starting. I assume that this is the first in a long chain of extended procs that would fail if I simply explicitly granted execute, and I have not had to do this prior to testing with application role permissions.
Both the database role and the application role have the same permissions, and I cannot see any permissions on the original user account or even on the extended proc beyond the role securables, so why am I being denied execute when using the application role?
Related
Would every user who uses my database have a role? Is it more administrators who will have roles, people who need access to all the tables?
Also, I am unable to offer table-level privileges to a role and offer that to a user.. it just won't work. I have to offer the privileges directly onto the user for them to work. Is that normal? Should I be able to offer table-level privileges to a role or do I have to manually offer each of my users the table level privileges?
Would every user who uses my database have a role?
That depends on how you (or, should I rather say, DBA) set it up.
Quite a long time ago, say until Oracle 8i, there were 2 very popular roles: connect and resource so when DBA created a new user, they simply ran
grant connect, resource to new_user;
and the new_user was ready to go as those roles provided most needed privileges such as create session, create table or create view (check documentation for more info about those predefined roles).
However, it turned out that not everyone should be granted e.g. create cluster (which is one of connect's privileges) so nowadays you should create your own roles, if you want - then grant certain privileges to those roles and, finally, grant roles to your users.
Another option is to keep .sql scripts for each of your users. That script should contain list of privileges granted to those users, separately, which means that you shouldn't granted anyone privilege they don't really need.
I am unable to offer table-level privileges to a role and offer that to a user. it just won't work. I have to offer the privileges directly onto the user for them to work. Is that normal?
It works, but not everywhere. Those privileges (the ones granted via roles) won't work in named PL/SQL procedures (i.e. stored procedures, functions, packages). If you have to use those tables in them, yes - you have to grant privileges directly to each of those users.
As opposed to named PL/SQL procedures, privileges granted via roles will work in anonymous PL/SQL blocks or at SQL level.
If you're wondering why would you use roles at all, then, the answer is my first sentence: it depends.
I'm using SqlServer and the application role for my application, but I also have username in SqlServer.
Is there any possibility to change user password when using the application role?
When I'm trying to change user password I get an error, that I don't have permission to change it.
I granted an alter permission to the application role, but it didn't help.
AFAIK, this is not possible and really isn't the use case application role was designed for.
Application roles are database level objects, or more accurately principals since it is a security object. Logins are server level principals. You cannot grant a server level privilege to a database level principal.
It really isn't the use case for app roles but if you absolutely must do it, you can create a stored procedure in the database used by the app and configure it to execute under a different principal but it's hacky and I wouldn't do it for a production system.
Problem
I have a SQL Server login that is allowed to create stored procedures, but not execute them. I cannot use another login to grant execute so I am looking for an alternative way to either run the code in the sp or to grant these permissions.
The EXECUTE permission was denied on the object 'sp_mystoredprocedurename', database 'mydatabasename', schema 'dbo'.
The user cannot grant execute to itself
Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.
Background
We have a Windows software application, written in Powerbuilder, that creates and updates the SQL Server database it works on itself.
On first startup the application prompts for a database admin login which it uses 1 time (we don't store this information) to create the database and a login. The login is given db_ddladmin, db_datareader and db_datawriter permissions. We currently have hundreds of these applications and databases running on servers managed by us, but also on our customers' own servers.
For this reason I would do anything to prevent the need to ask the user for a db admin login again so I can grant the execute permissions, which would be the easiest way... Downgrading all servers to SQL Server 2000 is of course also not an option :)
The stored procedure I am trying to implement is a "getnewid" method. Currently my Powerbuilder code uses multiple embedded TSQL statements to achieve this but because of network performance issues I would like to move these to a single stored procedure.
Does this help ?
CREATE ROLE db_executer
GRANT EXECUTE to db_executer
EXEC sp_addrolemember N'db_executer', N'<username>'
Try this.
GRANT EXECUTE ON sp_OACreate to UserLogin
GO
I have a mvc 4 web application that interacts with a sql server database over a number of environments.
The user I connect to the database with is different in each environment. I generate a generic script of my stored procedures during each build and deployment and run it in to each environment. In the script I grant execute permissions to the db user on each sproc.
At the moment I needed a script for each environment as the user is different in each - which is a pain!
Would it be possible to create a role in each environment, same name in each environment and grant execute permissions to the role as oppose to the user? The user would be set up as part of that role.
Yes, this is exactly what database roles are for, you create a custom database role, apply the permissions to that and then you simply add the user to that database role.
Have a look at the link below for details on how to accomplish this:
SQL Server - Custom Database Role
I've moved to creating/using schemas in Sql Server 2005, where I've also created database roles and assigned schemas to the roles.
The problem I have is one of the db roles I have should have full access - say SuperSysRole.
However, when I assign a login to that role, it cannot execute specific commands. In particular, I want a user within this role to manage password resets. However, when I execute the stored procedure, it does not return back all users in the database.
The stored procedure has been run which returns back the details and calls a view which integrates the sysusers and sysmembers tables.
The user, say myAdmin, has been assigned to the role SuperSysRole. The role SuperSysRole has been granted execute to the stored procedure selectRoles.
It's probably a simple thing but can someone please tell me what I am missing?
My application authenticates using the myAdmin user name and password. It works fine when I login with the sa account.
Database role membership is queryable through the sys.database_principals and sys.database_role_members catalog views, which are the proper catalog views to use instead of the deprecated sysusers and sysmembers. Both have the same security restrictions:
In SQL Server 2005 and later versions,
the visibility of the metadata in
catalog views is limited to securables
that a user either owns or on which
the user has been granted some
permission.
The necessary permissions are listed in GRANT Database Principal Permissions: VIEW DEFINITION. There is no permission that can be granted to view any principal and role definition.
Your best option is to create a procedure that selects from the proper metadata catalog views and sign this procedure with a credential that is added into the db_securityadmin role. See Signing an Activated Procedure for an example how to sign a procedure. The grant EXECUTE on this procedure to whoever required to view these principals and role memberships.
However, all of this will get you nowhere with regard with the declared intent: manage password resets. Only server principals (aka. logins) have passwords, and any scheme designed at the database principals level can have no effect on server principals, since they are the wrong abstraction. And since there are no server roles to define (you can only have Windows groups as roles, but you want to use SQL Auth), you cannot have this done by role membership.
My recommendation is, again, to use code signing. Create procedures that do the activities you want (query sys.server_principals and sys.sql_logins to inspect password expiration, issue ALTER LOGIN statements to reset passwords etc) then use code signing to sign these procedures and grant the required privileges to the signature. I refer you again to Signing an activated procedure for an example how to do that. Then grant EXECUTE on these procedures to the 'special' users that have to manage these.