I know I can set permissions on stored procs so that only certain users can call them. But is there any way to mark a procedure as "private" (in the encapsulation sense) so that no user can call it directly, but it can still be called by other procedures called by a user?
In Firebird 3 (in development), you can have packaged-private procedures and functions.
You may play with access rights.
Just can allow execution of "private" procedure just by specified procedure, user or role.
Related
I need to grant someone the permission to execute a bigquery stored procedure but I don't want to grant them roles/bigquery.admin, I would rather grant only the required permissions via a custom role.
This led me to question the who a stored procedure executes as. I have a background in SQL Server and there is an option there to have a stored procedure execute as owner which means that it runs as the owner of the stored procedure and thus the permissions assigned to that owner...but I don't think there's anything similar in BigQuery.
In short, how do I grant someone permission to execute a stored procedure and do I need to grant the person executing the stored procedure the appropriate permissions on the datasets affected by the stored procedure?
I've pored over the documentation, mainly https://cloud.google.com/iam/docs/understanding-roles#bigquery-roles, but I can't find anything that provides clarity on this issue.
What you describe "it runs as the owner of the stored procedure and thus the permissions assigned to that owner" is similar to the concept of "Authorized Routines". Unfortunately, per the REST documentation, "only UDF [routine] is supported for now".
I've filed a request in the BigQuery public issue tracker here: https://issuetracker.google.com/184160882 You may click the star button on the issue to follow it and show your interest.
Regarding the permissions needed, the bigquery.routines.get permission is required to execute a stored procedure or UDF. This is provided by roles/bigquery.metadataViewer and/or roles/bigquery.dataViewer. In addition, if it is not an authorized routine (which it can't be for procedures at the moment), then yes the query user also requires the appropriate permissions on the datasets affected by the stored procedure.
Resources:
BigQuery permissions
BigQuery roles
In UNIX (and, if my memory is not betraying me, in Linux too), there is a mechanism through which execute permission is given to users (that cannot access other files) but the program itself runs with different credentials, such that the same files the invoking users cannot access, the user of the program can.
Is there any similar (or equivalent) mechanism that would allow a DB-defined user only to execute a specific procedure and nothing else, while the same procedure would have permission to invoke any other procedure within the schema and, if needed, also access other DBs?
If you grant permissions to user to execute specific procedures then user will only be able to execute those procedures. Inside those procedures you can use same schema objects or call other procedures within same schema (called "ownership chaining") or other schema if that other schema is owned by same owner.
If needed, you can use "Execute As" for stored procedures so that user rights inside procedure are different from user that calls those procedures. That gets tricky in some more complex scenarios (e.g. dynamic SQL).
It gets more complicated if you want to call procedures from other database. In that case would recommend using certificates and procedure signing (Erland Sommarskog blog is execelent).
SQL Server ....
I have long been under the assumption that granting stored procedure exec to a principal means that the SP can do whatever it needs to do and optionallly return a result.
I am developing currently on a 2012 database. I created a SP and granted exec to a SQL login.
The user got error messages.
I also had to grant rights on a table and a function that I use inside the SP.
My world view also held that views and functions did NOT transfer rights in this way.
Has something changed? Have I just operated under a false pretense all this time?
I have googled for an answer, but cant seem to find an article that discusses this topic.
Any thoughts?
Thanks
Greg
Databaes chaining is the concept that addresses these type issues.
In 2005 forward, the notion of owner of an object became the notion of the schema that holds the object.
In my particular case, the stored procudure is in one schema , the function in another, and the table in yet another schema. Hence the need for these multiple grants.
I have never really used schemas before this assignment. Thats just how they do things here, and thats ok. Hence, my surprise at this behaviour.
Greg
If user defined functions are never executed outside the context of a stored procedure, what are the reasons one might grant permissions on SQL Server user defined functions?
Should we add grant permissions when developing database creation scripts that involve creating UDFs?
A user defined function can be used outside the context of stored procedures. It is good practice to allow this granularity in database object security.
I prefer to have permissions involving roles (data reader, data writer, reports, etc.) then yes use grant permission using the creation scripts.
Take a look at this http://technet.microsoft.com/en-us/library/dd283095(v=sql.100).aspx
My Asp.Net MVC web-site uses stored procedures based data access to the SQL Server database. Almost every procedure should check permissions, if current user can perform this operation. I've solve it by passing additional parameter UserId to every procedure and checking if user has special permission code in special table.
It causes many copy-pasted script. I wonder, is there any another way? Or may be you have an advices to improve my solution...
Just a thought, but what if you encapsulate the logic to lookup the permission for the given user and item in a user defined function. Then, invoke the function from the necessary stored procedures and check the return value. You still will wind up with some copying and pasting but in theory it should result in a cleaner approach.