Sentry grant select on only one table in database - apache-sentry

I am using Cloudera 5.4.2 with Sentry and am successfully granting access to roles on databases. My challenge now is to have a group that can read only one table from a database that has many other tables. I have not been able to grant select on a specific table where the role does not have any permissions for the database. When looking at the Cloudera documentation I do not see an example of this and the wording around granting table access makes is sound straight forward.
Here is an example of what I would like to run to get role test access to the table private_table without having access to any other tables in the database testdb.
CREATE ROLE test;
GRANT ROLE test to group `test-group`;
GRANT SELECT ON TABLE testdb.private_table TO ROLE test;

I also faced the same issue as in it granted the privileges for that table in default schema instead of "testdb" schema, every time I ran the following command:
GRANT SELECT ON TABLE testdb.test_table TO ROLE test;
I found a way to workaround this by doing this:
USE testdb;
GRANT SELECT ON TABLE test_table TO ROLE test;
However, since all Hive/Impala queries take DB.TBL schema, GRANT should also accept it.

Related

Create a user who can't delete data in influxdb?

Is it possible to create a non-admin user who can't delete data in influxdb?
I would like to create a user who can read/write (query/insert) data but not delete what has already been inserted.
According to what I can see in the official docs, I don't think I can. Is that correct? Or is there a sneaky workaround?
Non-admin users
Non-admin users can have one of the following three privileges per database:
* READ
◦ WRITE
◦ ALL (both READ and WRITE access)
READ, WRITE, and ALL privileges are controlled per user per database. A new non-admin user has no access to any database until they are specifically granted privileges to a database by an admin user.
GRANT READ, WRITE or ALL database privileges to an existing user:
GRANT [READ,WRITE,ALL] ON <database_name> TO <username>
No,
Deleting is a write operation. Write privilege allows you to make changes which can be adding, overwriting, or deleting things. Even if deleting was somehow restricted, if you can insert data then you can always overwrite existing data which allows you to destroy any actual data, essentially "deleting" it.
EDIT: as pointed out in the comment below, this applies for community edition of influxdb. Indeed the Enterprise edition supports more refined roles, and supports what the OP asked for, namely DROP_DATA role. Read more here https://docs.influxdata.com/chronograf/v1.7/administration/managing-influxdb-users/#dropdata and here https://docs.influxdata.com/enterprise_influxdb/v1.7/guides/fine-grained-authorization/

Roles based authorization in MVC4

I am new to MVC and want to understand the authentication mechanism in MVC
I have these tables in SQL, Users table, Roles table and UserRoles table which maps user id column to role id column. Now as soon as I add an attribute Authorize(Roles = "Customer") I want the access to be given only to the users having customer priviliges. Now what is is that I have to do to create a link between these two. I am looking for a step by step explanation or a link which points me to do this exactly, as I found a number of articles googling out on this and was unable to find the matching one.
Thanks in advance.
If you take the out of the box MVC template, you don't need to do anything to enforce this behavior. A database will be created for you as soon as you launch your application with a number of tables (Users, roles, mapping between users and roles, ...). Check your web.config for the connection string.
The only thing for you to do is to populate the ROLES table and then match those entries with the Authorize attribute in code. So if you have a role named "Admin" in the database, you can protect your actions and controllers with following code:
[Authorize(Roles="Administrators")]
You could also take it further to limit access by users but I wouldn't consider that as a best practice. Next, create a user in the UI and then match this user to a role you specified in the DB. Login as this user and you'll notice you have access to the restricted action/controller.
For more information, he best articles are those from Microsoft themselves, like this one.

What Stored Procedure can check logins (roles) information

SQL Server 2000.
Is there any SP can list what databases are owned by a specific login(role)?
Like:
EXEC sp_xxxx 'myloginname'
I want to see a set of database names that's owned by myloginname. Thanks.
Unsure what you mean. So, how about these to point you in the right direction?
sp_helplogins - Provides information about logins and their associated users in each database
sp_helpuser - Reports information about the Microsoft users and roles in the current database

Rights for running system procedures?

Can a non-adssys user run the system procedures?
I am developing a BizTalk WCF Adapter for Advantage that can be used and I need to browse and resolve the metadata. This is an add-in for Visual Studio, supporting .Net 2.0 or higher, that generates schemas and a binding file (wsdl). It can also generate classes that can be used in a WCF Service.
Our database has over 1000 tables, 50 views, and 50 procedures. We want to assign objects to a User ID and just return the objects belonging to the user.
Thanks,
Howard
Yes, non-adssys user can run the system procedures and use select to retrieve information from the system tables. Advantage uses a permission, and user/role based system to determine the user's access to the objects in the database. The user's permission will determine whether the procedure can be executed successfully or how much information are returned from the system tables.
This link provides the comprehensive information on the permission system in the Advantage data dictionary.
With regards to tables and views, to see the name of a table or view, the user must have at least the SELECT permission on the table a view. To modify table property such as constraint and index of a table the user must have ALTER permission to the table. For users who do not have ALTER permission to the table, those constrain objects and index objects are hidden from the them.
For stored procedures, the user must have EXECUTE permission on the procedure in order to see the name of the procedure.
The favored method for managing the permissions is to assign users to groups (roles), and grant permissions to the groups. User belonging to a group will inherit the permission from the group.
Conceptually, you might want to look at storing/retrieving the metadata from a descriptive table, then using THAT result to return your objects. You have a single point of access for all users using the ability to filter by SQL clause. Once you have the object data you can use a higher level permissioned "user" to return the objects without actually giving access to individual users. Just an idea.

Restrict stored procedure to only perform SELECT operations

Is is possible to restrict a stored proc to only SELECT from a database.
I want a stored proc which only selects data to execute correctly and a stored proc with UPDATE, CREATE, DELETE operations to return an error indicating insufficient permissions.
I am using Sybase 12.5
I think you're looking at the problem the wrong way. Essentially, once you give a user execute permission to a store procedure, they can execute that store procedure no matter what it does.
I think what you want to do is assign a "read-only" client role to your database and grant SELECT permissions as well as the execute permission on only the stored procedures that read data from the database. Add users to that role instead of granting them SELECT access on the database.
Separate writing and selecting actions to different procedures. And then allow selecting user to execute selecting procedures and writing user to execute selecting and writing procedures. This trick works pretty well with PostgreSQL.

Resources