I am using Aerospike 5.6 and I want to grant truncate to a role? is it possible?
can you please share how, I did not find the right privileges besides grant admin
According to https://docs.aerospike.com/server/operations/configure/security/access-control for Aerospike version 5.6 (5.1 - 5.7) the privilege responsible for truncates is “write” (Starting at 6.0 there is a dedicated privilege for truncates - "truncate").
A role is a set of privileges and a privilege consists of:
Permissions (such as truncate).
Scope (global, per namespace, per namespace and set).
Try (using asadm):
Admin+> manage acl grant role <role-name> priv write
Related
I'm experiencing a strange behavior in Snowflake and couldn't find any explanation in the documentation.
use role accountadmin ;
use database some_database;
create schema test_schema;
drop schema test_schema;
Result:
SQL access control error: Insufficient privileges to operate on schema 'TEST_SCHEMA'
When I check the schemas with show schemas I find that the ownership of TEST_SCHEMA belongs to another role.
Snowflake documentation only says that the ownership of an object is set to the role which created it, and the only way to have it owned by another role is transfer of ownership.
I've tried granting usage on future schema to accountadmin, but it hasn't fixed the problem.
Any ideas?
The database probably has future grants set up on it that automatically assigns ownership of each new schema created
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;
I am deploying a database in postgreSQL and I created a user that just will be able to execute certain functions.
I revoked all privileges from the user i just created and granted connect privileges executing:
REVOKE ALL PRIVILEGES ON DATABASE <database> FROM my_user;
REVOKE ALL PRIVILEGES ON SCHEMA public TO my_user;
GRANT CONNECT ON DATABASE <database> TO my_user;
But when i connect to the database with this user, i am able to read all table structures and all function source codes. Is there a way to hide it from this user?
I take the chance to make another question: I want to just execute functions (which may include select, insert or update on database tables) with this user, but I don't want to grant privileges on select, update or delete on tables.
I am using "SECURITY DEFINER" and then I grant execution, but I think it may be a little insecure. Am I right? is there any other way to do it?
Thanks in Advance.
Lamis
There's no way to hide the system catalogues from a user in PostgreSQL. If a user can't access the catalogues then they can't locate any other database objects.
If you really can't afford to let them see the structure of the db, you'll need to prevent them connecting. Build some sort of middle layer with a simple API that calls the db.
SECURITY DEFINER is the standard way to provide limited access at a higher privilege level. You have to be careful with any function arguments that can end up in a dynamic query though. That's the same "bobby tables" issue as with any dynamic sql building though.
How about
REVOKE SELECT ON pg_namespace FROM my_user;
REVOKE SELECT ON pg_catalog.pg_database FROM my_user;
You won't be able to see anything, but you'll be able to make queries if you know the namespace and table name.
What Server Role(s) and/or Database Role(s) must a SQL Login have to do the following:
Read Data (including Temp tables)
Write Data (including Temp tables)
Execute any SP within a database which they are granted access
We are migrating from SQL 2000 to 2008 and I'm going through all the Logins and have noticed they are all set to sysadmin & db_owner, which isn't good. Our apps that use these logins will only do what I've listed above so that's why I'm wondering. I know I can set each Login with a Database Role of db_datareader & db_datawriter but that doesn't include executing SP's. We've got close to 300 SP's in 2 or our DB's and to have to go through each SP and set the login permissions in the Extended Properties would be WAY too long and tedious.
Any help is greatly appreciated!
to have to go through each SP and set the login permissions in the Extended Properties would be WAY too long and tedious
And yet, this would also be the most secure.
Using the built in roles exposes too much of your database to your application.
Can you give the db_datareader and/or db_datawriter execute rights? This will give the user rights to execute any stored procedures in databases it has access to. If you have views you will also need to grant them select rights.
GRANT EXECUTE TO db_datawriter
I would either just deal with it and set the permissions manually or (my preference) create database roles that have the types of permissions you want to give, and assign logins to those. That way if multiple logins need the same set of permissions, you just give them the same role.
As a bonus, if your programmability objects have some sort of prefix naming convention so that (for example) procedures that read from your login information tables all start with something like pAccount_ or something, then you can dynamically do GRANTs to roles based on the prefix of the routine.
I am using LinqToSQL and a trusted connection to handle database selects/updates/inserts/deletes. In the past I have always used stored procedures and only granted execute permission to the Application Pool identity for the particular sproc in the database. This is my first LinqToSql project (and I really love how much it helps). I would prefer not to grant dbo access to the application pool identity to get LinqToSql to work (but if that is recommended then I don't mind). What type of permissions can I grant to the Application Pool identity so that LinqToSql will have the minimum permissions? Or should I just go with dbo permissions and be done with it?
As per KristoferA's answer this is the permissions I granted the application pool identity in the database:
EXEC sp_addrolemember 'db_datareader', 'app_pool_identity'
EXEC sp_addrolemember 'db_datawriter', 'app_pool_identity'
Not exactly the same level of security as only granting execute permissions to the necessary sprocs but I am very good with it considering the huge development gains I have achieved just by using Linq2SQL. And it is better than granting the full dbo access.
db_datareader and db_datawriter is enough if you just want to read and write data without messing around with schema changes and stuff...
LinqToSQL creates dynamically generated SQL. As such, it needs full access to the data manipulation language commands (insert, update, delete). Your application account should not need access to data definition language commands (create, drop, alter, etc.).