Since LoginA is not member of sysadmin server role, the login must need IMPERSONATE permissions to use EXECUTE AS i.e.
CREATE USER LoginA for login LoginA; -- This will create user under "public" database role
GRANT IMPERSONATE ON USER::LoginB to LoginA; -- This is required to use "EXECUTE AS"
Once LoginA got IMPERSONATE access, you can create ...
Instead of using OPTION (QUERYTRACEON 9481), here is a proposed solution/workaround .
It allows a non-sa user to change the Cardinality Estimator for the specific statement, query, or procedure call (for the current session).
Wonderfully explained by Kimberly Tripp in her post on sqlskills.com:
"Setting CE TraceFlags on a query-by-query (or ...
To grant default privileges, U actually need to grant rights to the user you are creating the table with.
e.g.: you're creating the tables as SA_user, but reading the tables als READ_user.
you're code needs to look like:
ALTER DEFAULT PRIVILEGES
FOR USER SA_user
IN SCHEMA schema_name
GRANT SELECT ON TABLES TO READ_user;
So whenever the SA_user creates a ...
SQL Server Agent will schedule a job and cause it to be run by the SQL Server service - the database engine. The account which is trying to create this snapshot for your CHECKDB to be run concurrently with users in it is not the Agent service, but the SQL Server service. So look to see who your SQL Server service is running as and what permissions that ...
If you are administering databases often, you will likely want to keep tight privileges. You can use a stored procedure to quickly run a check. This example works in mariadb might need a tweak to work with the standard mysql version.
Using the answer from Mansur Ali with a little tweak reordering the columns and adding in some ordering to better organise ...
You would have to
REVOKE EXECUTE ON FUNCTION ... FROM PUBLIC;
because that's the default privilege for functions.
Revoking a privilege that was not granted is a no-op in SQL.
After revoking the privilege from PUBLIC, you'd have to explicitly grant it to all users that should have it.
But I think you shouldn't do that.
These modifications will ...
Write an event trigger that throws an error whenever the user tries to drop a table:
CREATE FUNCTION no_drop_table() RETURNS event_trigger
LANGUAGE plpgsql AS
IF current_user = 'myuser' THEN
RAISE EXCEPTION 'you may not drop tables';
CREATE EVENT TRIGGER no_drop_table ON sql_drop WHEN TAG IN ('DROP TABLE')
As the manual says,
To alter the owner, you must also be a direct or indirect member of the new owning role, and that role must have CREATE privilege on the table's schema. (These restrictions enforce that altering the owner doesn't do anything you couldn't do by dropping and recreating the table. However, a superuser can alter ownership of any table ...
DENY overrides GRANT, and an inherited DENY even overrides a direct GRANT. And a DENY at the schema or database level overrides a GRANT at the object level.
So you won't be able to directly override the DENY.
You can create a view, synonym, or stored procedure owned by the same user as SuperSecretData and grant them access to that.
is there a better ...
You'll need to create the logins on each instance (box), but you can only set up the user mappings on the one that is currently acting as the "primary" for that AG (the one that is not read only).
If you fill out all the necessary information in the "New Login" dialog, including the "User Mapping" tab, then click the "Script" button at the top, you end up ...
ALTER USER root@localhost identified via unix_socket;
now works for the root user without password.
The statement *"The unix_socket authentication plugin is also installed by default ..."
does have no effect if you migrate from Oracle's mysql to ...
Now you can probably login by
sudo mysql -u root -p
and entering the password from your ALTER USER statement when prompted.
Once you're in the console again you can reset the password to empty like:
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';
And it should start to allow you with just sudo mysql as before.
Your problem is very simple.
You have grants to do things in any existing database that starts with lamp_.
You do not have permission to create a new database even if it starts with lamp_.
You would need at least GRANT CREATE ON *.* to create databases.
You misunderstood the phrase
Requires membership in the sysadmin fixed server role, or ownership of
the database (dbo)
"ownership of the database" means that this login owns this database.
This is not the same as "is a member of db_owner database role"
Owner of a database is one single login, while there may be as many db_owners as you want.
And in ...
Before the changes actually take action, you need to run
Just saw that you tried to grant Privileges on a database which doesn't exists. You need to give them global privileges to create databases.
Occurs that this sp_updatestats behaviour is some kind of a bug.
One way to solve it is to use another sp and then grant the user execute permission (if not db_owner):
CREATE PROCEDURE dbo.updstatistics
WITH EXECUTE AS 'dbo'
GRANT EXECUTE ON dbo.updstatistics TO [<user>];
The easier way to do it is to change the service account of the SQL Server Reporting Services service via the SQL Server Reporting Services Configuration Manager (SSRSCM).
When you change the service accounts using SSRSCM the permissions for the required directories, modules, etc. are all set correctly.
During the process you may be asked to secure the ...
The user that has access problems is the member of many win groups,
even if he's a member of db_owner he has limited access if someone revoke/deny some permissions to him or to his group.
To find out restrictions you should use this query:
execute as user = 'NETONE\İbrahim.tackin';
select user_name(grantee_principal_id) as user_,