I'm experiencing a recurring problem whereby a user's CREATE SYNONYM permissions within TEMPDB are being lost. Is there a reason why these permissions do not seem to be permanently persistent?
The error I am getting:
> System.Data.SqlClient.SqlException (0x80131904): CREATE SYNONYM
> permission denied in database 'tempdb'
I left you the comment but what you can do is the following
create a proc in the master database, in that proc give the permissions for the tempdb (you can use USE tempdb in the proc if you use dynamic sql)
then mark the proc to run at startup
exec sp_procoption N'MyProcName', 'startup', 'on'
Now everytime sql server is restarted, this proc will run and give the permissions
See also here List all stored procedures that run at startup in SQL Server
tempdb is created as a copy of the model database every time the server is restarted. My guess is that there's a server restart happening between when you grant the permission to the user and when you get this error message. That said, you can either grant the permission in model and it will be in tempdb when the server restarts or you can do something like creating a startup stored procedure to grant the permission in tempdb.
Related
I've been struggling to get the total capacity of a disk drive where SQL Server is installed; I know I can achieve that with sys.dm_os_volume_stats or xp_cmdshell but to run the query you need some permissions like VIEW SERVER STATE or ALTER permission.
Is there a way for a normal user to get the full capacity of the disk without granting special permissions?
You can Execute any Stored Procedure or Table Value Function as a specific caller :
CREATE PROCEDURE dbo.MyProcedure
WITH EXECUTE AS 'domain\user'
AS
...
More info in StackOverflow
More info in MSDN
Also, If you got a Certificate problem :
Signing Stored Procedures with a Certificate
We use FlyWay as a migration tool to manage our database version.
Recently we added two stored procedures in repeatable scripts, one of which uses user defined types (CREATE TYPE). The other calls the former.
The account I use in my deployment script is not the db_owner on master (the account you get from the Azure portal). Instead, I created a separate deployment account on the database in question, initially only as db_ddladmin, and now upgraded to db_owner so that it can GRANT EXEC on the user defined types.
However, the second procedure consistently fails when I try to run the migration using this account:
Migration R__21Proc_ConflictsForUI.sql failed
---------------------------------------------
SQL State : 08S01
Error Code : 0
Message : I/O Error: Connection reset
Location : ./db/Stored Procedures/R__21Proc_ConflictsForUI.sql
Line : 5
Statement : CREATE PROC Conflicts_For_UI #CustomerId INT, #TotalRows INT = 20
When I try to run the same migration using my portal db_owner account that is also on master, it works.
Why would Azure close the connection on the second procedure, but not the first?
By doing just GRANT EXEC you gave the permission on execution, but to be able to CREATE PROC that REFERENCES UDT, a user should have REFERENCES permission on UDT.
Alternatively you can grant CONTROL on UDT that will bring to user
REFERENCES
EXECUTE
VIEW DEFINITION
TAKE OWNERSHIP
on UDT
I have a stored procedure that I can execute in SSMS with a non domain SQL Server user.
This stored procedure selects data from tables in one database (DB1) truncates and selects into a table in DB2.
The user has datareader,datawriter and dbowner for both databases.
Problem:
When I execute the stored procedure via SS Agent with execute as the user I get the following error
The server principal [user] is not able to access the database [DB1]
under the current security context.
Actions taken So far:
I have tried to resolve this so far by:
Turning on db chaining for both databases
Deleted the user from DB1 and added again
Checked using EXEC sp_change_users_login #Action=’Report’ to see if user orphaned. As this is a database that is a restore of a live one. However I added the user after the restore. The user was not listed as orphaned
A possible workaround if you don't want to have the owner be sa is to have the user be a member of msdb and grant the the SQLAgentOperatorRole in msdb. See if that works.
But to be honest, either use sa or a dedicated service account with enough permissions. It's better if the job runs under that context.
My requirement is that user performing alter CANNOT be sysadmin (it can have all other rights but not sysadmin).
I am running a query from local server which should modify a remote one
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB') at [REMOTESERVER]
This query works once I add sysadmin right to the user but without the right, it give the following error:
The server principal "USERWITHOUTSYSADMIN" is not able to access the database "REMOTEDB" under the current security context.
I am on SQL Serve 2008.
Please Help!
After much research: This is not possible:(
Put the EXEC command in a stored procedure and grant execute on the procedure to the user. It won't STOP a sysadmin from executing it, but it will allow others to execute it as well. Be VERY, VERY careful with this!
Can you allow the user to impersonate someone with the appropriate permissions?
EXEC ('ALTER DATABASE REMOTEDB MODIFY FILEGROUP ftfg_REMOTEDB NAME=ftfg_REMOTEDB')
AS USER = 'UserWithAppropriatePermissions'
AT [REMOTESERVER]
I have a SQL Server 2005 database that is suffering from lock starvation because of some poorly behaving applications running cursors through sp_prepexec. I imagine that one of the applications running a cursor has "forgotten" to close it. I would like to deny access to sp_prepexec for specific users to prevent the lock starvation from occurring in the production database.
When I'm attempting the following syntax:
use master
deny execute on sp_prepexec to applicationUser
I have to use master because when I don't: Permissions on server scoped catalog views or system stored procedures or extended stored procedures can be granted only when the current database is master.
But the problem is that applicationUser is not a user in the master database. So I get the following error:
Cannot find the user 'applicationUser', because it does not exist or you do not have permission.
If I add that user to master it doesn't seem to prevent applicationUser from running sp_prepexec in the production database.
Can somebody point me in the right direction with this?
Could you deny the permissions to a role, rather than a specific user?
USE master
GO
DENY EXECUTE ON production.sp_prepexec TO public
GO