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).
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
I am configuring the database accounts for some new users. I have come up with the following solution which is 99% of the way to getting the accounts to work but I have hit a problem which I cannot resolve.
Firstly, I created a new login with SQL Server authentication and then gave them the EXECUTE permission to all stored procedures. This allows them to run them all but they cannot view the code and they cannot view the database tables.
Inside the stored procedures I added the following:
WITH EXEC AS OWNER
This allowed the stored procedures to run as the default account we normally use and this has the role of db_owner. This allows the new users to run all the stored procedures and it works great until I hit the following problem:
Some of the stored procedures (all of which are using dynamic SQL) call some synonyms which link to tables in two other databases (history and a data mart database). This gives me the following error:
The server principal "{username}" is not able to access the database "{database name}" under the current security context.
The account which I am using in the WITH EXEC AS is the db_owner of all three databases I am working with.
What can I do to resolve this problem? Many thanks
EXECUTE AS Owner is a database sandbox. Think about it, it has to be. Otherwise a database administrator can issue and EXECUTE AS USER = 'somesystemadmin' and elevate himself to an instance level administrator. The details are described in Extending Database Impersonation by Using EXECUTE AS:
when impersonating a principal by using the EXECUTE AS USER statement, or within a database-scoped module by using the EXECUTE AS clause, the scope of impersonation is restricted to the database by default. This means that references to objects outside the scope of the database will return an error.
The solution is simple: sign the procedure. See Call a procedure in another database from an activated procedure for an example. Read more at Module Signing and Signing Stored Procedures in SQL Server.
I'm confused by the example at this link. A similar example exists here but I prefer the first one. Briefly here is the summary of my confusion:
A user (examplecertuser) is created from the certificate.
Rights are granted to the user (examplecertuser) created from the certificate.
A signature is added to the stored procedure using the certificate.
Then a test is done using a separate login (testuser) that has no relation to the previous. This is what I don't understand.
I'm not sure why the examplecertuser is created or what purpose it serves. More importantly, since no connection is made between the login (testuser) and the certificate created user (examplecertuser), this means that ANY LOGIN is able to run the stored procedure. I verified this by creating another login and having it also run the stored procedure.
I am looking into this to avoid database ownership chaining as per all the recommendations I read. My goal is to grant a user the ability to run a stored procedure which spans several databases but limit them to just running that stored procedure. Using the example I see listed, I think I would be granting everyone the ability to run the stored procedure with no way to limit others from it.
To rephrase the question in a more direct format, "how do you use the sample in the link to only allow selected logins to run the stored procedure?" The user (examplecertuser) seems to be the key to authorization but I don't see any linke between the user and a login.
Code signing gives you the ability to grant permissions to an underlying object under certain circumstances (as opposed to any time). Say, for instance, that I have a table with sensitive information in it. I don't want just anybody selecting from it (that is, writing "select * from myTable"), but I'm okay with giving them access through a stored procedure (so I can limit what they can select with business logic). So I go through the exercise of signing the stored procedure. I can still grant (or deny) execute permissions on the procedure to individual users. But when the permissions are checked for the underlying objects that the stored procedure accesses, it will apply the permissions of the module signing user (examplecertuser in your example).
With respect to your specific questions
Only users that are granted execute permission on the stored procedure will be able to run it
In order have this permission span multiple databases, you'll need to create the certificate and associated user in each database.
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
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.