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/
Related
Recently something is changed the way Graph is handling permissions on drive items for external(outside tenant users).
Previously when we give access Write access to an external a unique link was created per user that we can do a patch call to update the roles if we want.
Now only two links are created one which is common for all externals having write role and one for read role.
I could not find a way if I want to update the role of an external from write to read or vice versa without removing all external users with write and adding them again.
Is there a work around to update permissions for external. The documentation is also pretty old its not updated since 2017.
Note: This is the Endpoint we are using/recommended to update permissions.
In the official Documentation (3.1: http://neo4j.com/docs/operations-manual/current/security/authentication-authorization/subgraph-access-control/)
It is said
"For example, a user can be allowed to read, but not write, nodes labelled with Employee and relationships of type REPORTS_TO"
But nowhere it's written in this page and others how to do it.
With the "call dbms.procedures()" we can see many more function in the enterprise edition but nothing about defining this Subgraph control
We think on changing the an enterprise edition, but if we are sure to be able to do that.
Can anyone explain me or gives me the address of the relevant documentation
Thanks
The documentation is all right there. Note the first sentence:
Through the use of user-defined procedures and custom roles, an
administrator may restrict a user’s access and subsequent actions to
specified portions of the graph.
The approach seems to be, for users without write permission, create roles for them as appropriate, then create (or use existing) user-defined procedures to do what operations they are allowed to do. Then configure the permissions of the procedures to the appropriate level, and associate the roles of the procedures (by modifying dbms.security.procedures.roles) with the roles you previously created. This allows the procedures you created to be executed by the roles you associated it with.
For example, given an HR user, who does not have write permissions, you could create a procedure to create or delete a :REPORTS_TO relationship between :Employee nodes. The procedure would need to be set to mode=WRITE since it needs write access. This would normally not be executable by this HR user, since they don't have write permissions.
But if you created a role, say 'hr', and added that role to this user, and set the procedure to be accessible by the hr role in dbms.security.procedures.roles, then the hr user could execute this procedure, and it would perform the necessary write operations.
In summary, Neo4j's subgraph access control isn't defined on the nodes or labels themselves, nor does it apply when executing write statements in Cypher. This access control is specific to user-defined procedures, and allows users with certain roles (where that role is associated with those procedures) to execute those procedures even if they normally would not be able to due to their access level.
EDIT
One final thing that could work for you...Neo4j has a means of registering transaction event handlers that can perform checking and logic on a transaction in progress, and reject if some criteria are not met. I would assume you could get a user's roles here, and probably check the transaction for writer operations on certain labels. Odd that this wasn't referenced in the securing the subgraph section of the documentation. I haven't tried this approach myself (I'll try my own testing later) so I'm not sure if it will fulfill what you need, but it's worth a look.
UPDATE:
It's been awhile, but we do have a more comprehensive means of access control coming to the upcoming Neo4j 4.0.
4.0 will include schema-based security, full ability to define, per user and role, the ability to grant or deny various levels of permissions (read, write, traverse, and more) for nodes and relationships of specific types. So for example you can have various roles that only have visibility on certain kinds of nodes, or are specifically denied visibility on others. You can also restrict whether certain nodes can be traversed through at all.
This should fulfill the needs of everyone who has been waiting for a more comprehensive security and access solution in Neo4j.
Here's the Neo4j 4.0 MR2 documentation, more to come as we approach the official 4.0 release!
New at ASP.NET MVC. I am looking for some UI design ideas not entirely specific to MVC. There is probably not an exact answer but here is what I have started.
There would need to be a page with 3 tabs on it.
Permissions | Groups | Users
1) Permissions View would allow you to do CRUD operations on Permissions in a Grid
Delete on a specific permission is only allowed when the permission is not being used in any Group.
2) On Groups View, CRUD operations on Groups are allowed in grid.
Also, a Permissions link is provided that will allow to do mapping (Add/Remove) Permissions for a Group
Again, a DELETE operation on a Group is only allowed when the Group is not being used by any User.
3) On Users View, all the existing Users in the system will be presented. The grid show allow for searching a user by username, first name or last name.
Groups link should be provided for each user that when clicked allows to do mapping (Add/Remove) Groups for a User.
Below this mapping in the same view, a separate section of Permission Overrides should be provided so that a specific permission can be added with IsGranted (true/false).
Description of the database design:
1) Groups will be assigned Permissions. Based on the group that the user belongs to, User will get the Permissions.
2) UserPermissionOverrides will handle the scenario where
- a User needs to be granted certain permissions (regardless of the role they are in) or
- if certain permissions need to be revoked from a user, even if they belong to a certain group.
This will allow us good flexibility to handle the special scenarios of adding or removing specific permissions.
So, when the user logs in - 1) above will be used to retrieve the group permissions for a user and then 2) will be executed to retrieve the overrides (granted/revoked). Combining 1) and 2) will give us the final permissions for the user which will then get stored in the forms authentication cookie to prevent further database hits
Your model and functionality all make sense to me. However, I think you need to revisit the UX principles you are employing for the interface.
Write a few user stories i.e. what a user of the security system intends to do and what goal they need to fulfill for that visit.
You need not always tightly couple your UI to your model i.e. just because you have structured your model in a certain way, those entities needn't be presented as principle objects for CRUD operations to a user. It's probably very unlikely that a user of the system will come in, add a permission and leave.
Pertaining to the above, personally I would approach your user permission UI as a wizard rather than a set of tabs:
Step 1: Pick a user or add a user.
Step 2: Which roles do they need (offer the opportunity to add a role).
Step 3: In which groups do they belong (offer them to add groups here if necessary).
... or similar.
Basically, your aim should be to get your user in and out of the system as quickly as possible. I think the act of creating user stories and wizards you glean from them would be the method I would employ in the UX design of your system.
Good luck!
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.
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.