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.
Related
I don't know why but I can not see the stored procedures appear when I connect the database to Tableau (I use MariaDB). I can only see the data tables.
Anyone has the same problems with me? I am a newbie so I am not sure if my description is clear or not.
Use the stored procedures.
I found that Tableau does not connect to stored processes and that one way around this is that when you connect to your server, you should use the initial query function. Once you log in, grab Custom SQL and for that script simply use
select * from #nameoftemptable
and Execute.
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/
I want to get the details of the Deleted Stored Procedures and Functions
Also i want to get the info like when it was created & removed in DB.
Please guide me.
Thanks in Advance...
You can see when procedures and functions were created by looking at the CREATE_TIME column tables in the system catalog like SYSCAT.PROCEDURES and SYSCAT.FUNCTIONS.
You will have no way of knowing when these objects were dropped unless you enable auditing within the database (and review the audit logs to find instances of DROP PROCEDURE or DROP FUNCTION).
If I create a store procedure, named test, that contains lots of different columns from many different tables.
I wanna let 20 users to get access to the data with stored procedure via excel.
My question is:
Is it possible to make the user to get access only to the store procedure, test, only? Users shall not have access to table or view. Store procedure test only. I'm using SQL server 2008 R2 standard
http://msdn.microsoft.com/en-us/library/ms188371.aspx access to the single stored procedure and no permissions to the table.
Grant EXECUTE On [SpName] To [Principal]
There is no such concept as a read permissions to a table for a stored procedure. Stored procedure permissions are separate from other objects. If a user has permission to run a stored procedure, they can run it no matter what it does, even if they don't have permission to the underlying objects
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.