I have a gitlab user and a role assigned to it, now the gitlab user needs extra grant permissions.
I am executing the following sentence. [ssms 2012]
GRANT VIEW SERVER STATE to xxx;
ERROR:
Grantor does not have GRANT permission
What is the permission i should give to gitlab user so that it can give grant permissions to another user.
I have also tried this but same error
grant view server state to xxx with grant option
please tell me as a command
The error is pretty clear - the account that you are using to run the script does not have WITH GRANT permission and therefore it cannot give it to someone else. Check with your DBA.
Related
I have given grant all privileges to role svn_dev, but it is not giving access to create, alter and drop stage permissions across all schemas. How do I provide this to a role?
I have also tried
grant ownership on database DA_DEV to role svn_dev;
I get an error
SQL execution error: Dependent grant of privilege 'CREATE SCHEMA' on securable.
To revoke all dependent grants while transferring object ownership, use convenience command 'GRANT OWNERSHIP ON <target_objects> TO <target_role> REVOKE CURRENT GRANTS'.
How to give create stage permissions?
The error message gives a way to fix it in most cases. Try this:
grant ownership on database DA_DEV to role svn_dev revoke current grants;
If you can't revoke current grants because it would be too much work to re-issue the grants, you can explicitly revoke the grants that are preventing a change in ownership. You can check them using show grants.
You can grant create stage like this:
grant create stage on schema <DATABASE>.<SCHEMA> to role <ROLE>;
I have some stored procs under schema dbo.
I also database level role: Tech, and a database level user: Jack. Jack is a member of Tech.
As sa I am able to run:
GRANT EXEC ON SCHEMA :: dbo TO Tech
Then Jack would have EXEC permissions to all stored procs. Now what I wonder is that whether or not there is a way for me to run the same command not as sa, but as Jack, to grant the same EXEC permissions to other users which Jack created(Jack does have permission to create server level logins, database level users/roles etc.)? In other words, what permissions does sa need to give to Jack so that Jack can grant EXECs to all stored procs under schema dbo?
Update: I just tested and found out that granting CONTROL on schema dbo to Jack can do it. My question now becomes: is CONTROL the absolute minimum that's needed to enable Jack to grant EXEC on schema dbo?
If you need to GRANT someone permissions on something, and give them the permission to then GRANT it to someone else, you need to do your GRANT using the WITH GRANT clause.
After testing, it seems that WITH GRANT OPTION only works on an user, but not on a role. Use the example in my original question, we have role Tech and user Jack, where Jack is a member of Tech:
Running GRANT EXEC ON SCHEMA :: dbo TO Tech WITH GRANT OPTION; will not enable Jack to then grant EXEC to other users.
However running GRANT EXEC ON SCHEMA :: dbo TO Jack WITH GRANT OPTION; will work.
Greg's answer is in a way correct and he should get credit. Although since I have figured out the specifics myself, I will use my own answer.
Update: Further information, found this in the Microsoft document:
The GRANT ... WITH GRANT OPTION specifies that the security principal
receiving the permission is given the ability to grant the specified
permission to other security accounts. When the principal that
receives the permission is a role or a Windows group, the AS clause
must be used when the object permission needs to be further granted to
users who are not members of the group or role. Because only a user,
rather than a group or role, can execute a GRANT statement, a specific
member of the group or role must use the AS clause to explicitly
invoke the role or group membership when granting the permission. The
following example shows how the WITH GRANT OPTION is used when granted
to a role or Windows group.
I am currently importing a dump file inside RDS Oracle 12C instance using impdp command.
Prior to that it is required to create few users & grant them required privileges.
I have following statements that I use on other non-rds databases.
GRANT UNLIMITED TABLESPACE TO "USERNAME"
GRANT "RESOURCE" TO "USERNAME"
GRANT "CONNECT" TO "USERNAME"
GRANT "EXECUTE_CATALOG_ROLE" TO "USERNAME"
When I run these prior to import, these commands return grant succeeded.
Now, when I run impdp, I get following errors in log:
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
ORA-31685: Object type SYSTEM_GRANT:"USRNAME" failed due to insufficient privileges.
Failing sql is:
GRANT UNLIMITED TABLESPACE TO "USERNAME"
ORA-39083: Object type ROLE_GRANT failed to create with error:
ORA-01924: role 'CONNECT' not granted or does not exist
Failing sql is:
GRANT "CONNECT" TO "USERNAME"
Same for other privileges as well.
I am running these commands using admin user that was created while spinning up the instance.
I have seen there's a different way of granting in AWS RDS on this link
How do I map that with what I'm trying to achieve here?
I'd suggest you NOT to use RESOURCE and CONNECT roles. These were popular back in 1990s as they contained the most common privileges one might need. However, best practice says that you should grant only privileges that are required for a certain user.
CONNECT nowadays contains only CREATE SESSION. RESOURCE contains several CREATE something privileges (table, procedure, trigger, ...) (query DBA_SYS_PRIVS to see them all). Do you really need CREATE CLUSTER? If not, well, don't grant it.
Try to add those privileges separately:
grant create session to username;
grant create table to username;
grant unlimited tablespace to username;
grant *whichever additional privilege USERNAME requires*;
Finally, just in case you didn't read it, this is the Importing Data into Oracle on Amazon RDS documentation, have a look; perhaps you'll find something useful.
Your case deals with a very specific situation Oracle Database permission to user. To grant a ALREADY EXISTING USER such a privilege (QUOTA UNLIMITED) is has to be done with this command:
ALTER USER xxxx_userName QUOTA UNLIMITED ON yyyy_tablespaceName;
Someone created a database and I am a super user in PG Admin. When I tried to access the database tables by clicking on it, I received the error message "permission denied for relation table_name". It's a table for the Mayan database. I tried all kinds of methods, but I am unfamiliar with this and not sure how to go about doing it. I opened the SQL editor and entered the GRANT commands to grant myself access, but I keep getting "permission denied". I am using PG Admin.
Can anyone tell me how can I be granted access to the table?
To access a table you have to grant privileges to the tables with GRANT. First enter to the database and open a SQL editor then execute one of the next queries:
-- For all privileges
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO user
-- For viewing privileges
GRANT SELECT ON ALL TABLES IN SCHEMA public TO user
Note that you have to specify the schema.
I need to grant a db_datawriter before executing SqlBulkCopy and remove it after:
try
{
"EXEC [db_mod].[sys].[sp_addrolemember] N'db_datawriter', N'my_user'" // via SqlCommand
bulk.WriteToServer(table);
}
finally
{
"EXEC [db_mod].[sys].[sp_droprolemember] N'db_datawriter', N'my_user'" // via another SqlCommand
}
but I'm getting an error:
User does not have permission to
perform this action.
How can I fix that?
Try using GRANT and REVOKE.
Wouldn't it be easier to just grant that user that runs the SqlBulkCopy (which inserts data into just exactly one temporary staging table) full rights on that single table only?
Something like:
GRANT ALL ON (temporaryTable) TO my_user
That should be sufficient to do the SqlBulkCopy operation.
In order to run the GRANT command, the user running that command must have the necessary permission to do so - see SQL Books Online on that topic (GRANT (Transact-SQL)).
Marc
MSDN sp_addrolemember tells you what rights are needed...
Membership in the db_owner fixed database role.
Membership in the db_securityadmin fixed database role.
Membership in the role that owns the role.
ALTER permission on the role
Practically, you'd need to be in the db_securityadmin role.
However, why not just persist INSERT/UPDATE rights via GRANT? The right to grant yourself rights implies enough privilege to not need any more rights...