I'm assuming that it CAN be done, I just don't know how or haven't been able to find a way to do it.
In Oracle, can access to the ALL_* tables and USER_* tables be revoked, including select grants.
For example, the all_objects, all_procedures views. Can access to these be restricted?
The same goes for user_tables and user_procedures and any other user_* views. Can access to them be restricted?
No, you can't (reasonably) prevent users from being able to query the ALL_* or USER_* views. You could go through and individually revoke access to each and every one of these views from PUBLIC but that would be a rather painful effort to go through, it would cause all sorts of applications to break not to mention breaking scripts from Oracle. You would end up, at a minimum, re-granting access to those views to any account that connected to the database because every database API interrogates the data dictionary views. Whether you have an ODBC application, a JDBC application, a PL/SQL IDE like TOAD or SQL Developer, or just about anything else, those applications will need to query the data dictionary.
The data that they will see in either view, however, will be limited to the objects that they have access to (for the ALL_* views) or the objects that they own (for the USER_* views). What purpose would be served by restricting a user's ability to query the data dictionary to determine what objects the user owns or what objects the user has access to? It would seem extremely odd to want a user to own a table but then to not allow the user to know that he owned that table.
Now, if you are really determined, you can create objects in the user's schema (tables or views) named, say, ALL_TABLES or USER_TABLES. Assuming that the user just queries ALL_TABLES rather than specifying a fully qualified SYS.ALL_TABLES, they will be querying the local object not the data dictionary view. That is generally a very inadvisable thing to do-- lots of products work by querying the data dictionary so causing the data dictionary queries to return the wrong set of data can lead to all sorts of bugs that are terribly hard to track down. But it is an option if you really, really want to restrict what data is returned from the data dictionary.
Related
I have an Oracle database and need to periodically access some data from the v$database view in my SpringBoot app. v$database is a special view that has just one row and contains some internal DB constants and variables. Basically I would like to fetch CHECKPOINT_CHANGE# from that one row via a query such as:
SELECT CHECKPOINT_CHANGE# FROM v$database;
Normally, you would use the Spring Data Repository abstraction along with #Query for your usual tables/views and I'm sure that would work here, as well. But considering the fact that v$database is a bit "special" and only has one row, it seems a bit over the head.
How would you approach this?
There is nothing special about it as far as the user is concerned. It queries like any other table. Under the covers, it is an interface to the control file rather than a data segment, but that is only of interest on the back-end. Just don't try to ask for ROWID. And you will need the "SELECT ANY DICTIONARY" privilege to query it, as with all SYS-owned dictionary views.
Env: Oracle 11g DB with a Java based application
We are looking to encrypt data in our database, for a few sensitive columns of a table.
We would like these columns to be decrypted and visible to a set of users A.
And we DO NOT want these encrypted columns to be visible to another set of users B.
But, this user set B should be able to see the rest of the non-encrypted columns of the table.
From various articles and posts, I understand TDE does encryption and decryption transperantly and at column level, but have not been able to find clear information if the above user/role based encryption, at a column level granularity is possible or not.
Can we achieve the above using TDE?
I'm not a DBA, but from my understanding of TDE the encryption is not noticeable when viewed from any query. It only encrypts the data in the disk data file so it can't be read if dumped directly from the file.
A good DBA may have a better answer but just off the cuff, here is what I would suggest.
Have two fields for the sensitive data. One is clear (though TDE may be a good idea) and the other is obfuscated in some way. These fields may be normalized into a separate table. Don't allow access directly to the table but use a view instead. The view would be defined like:
create view TableName as
select ...,
case ROLE when 'A' then clear_field else obfuscated_field end as FieldName,
...
from SensitiveTable
join PossibleNormalizedTable on ... ;
You would also need triggers on the view. If only A can clearly see that field, probably only A can insert and update it.
I am newbie and have a design question.
The question may be vauge but I will try anyway.
Assume that we 2500 file objects in the system. We have users that have access to certain files.
When we display different view of files or objects associated to files we need filter the view depending on the logged in users access to files. If every view requires the application to run through all files I guess it is bad for peformance. What is general practice to handle such situations? Make a cache of the files the logged user has access to?
This is a general question but I can still add that we are using MySQL and Hibernate.
Thanks!
I think if you works with 2500 files - then probably it's not a problem for performance. Amount is't very big. But numbers could grows faster.
So as I see you use some relational database. Create a table for your files (Files), create a tables for your user (Users) and UserFileMapping table (to store user to file relation). Your goal is to implement many-to-many relation with user-to-files. This is tutorial how to implement it.
Then you could query all files per user with simple expression like
Select distinct from Files inner join FilesUserMapping on File.ID == FilesUserMapping.FileID where FilesUserMapping.UserID == 'your_user_id' (query is very approximate, I'm not working with sql for a long time and forget a lot of the stuff)
It will return all the files for your user and will made it in very effective manner, because databases have very good optimization.
First of all I won't to say that I'm an expert in database handling, and less so in oracle. However right now I need to get better at it :)
I'm using nHibernate as orm, to my oracle database. It works ok, and is rather simple to use. However now I have run in to a problem that I don't know how to solve.
In the Database theres a kind of tree with the tables, views, indexes and such. At the end there are also a entry called "Other Users" in which there are some users with access to what I'm guessing is other tables. Now I would like to get data from one of those tables (I can read them manually in SQL Developer, so it's not a access problem or anything). Does anyone have any idea how I shall do that?
The account that you use in SQL Developer has at least read privilges to tables in another schema (owned by another user). You can access these tables by prefixing the table name with the schema name. In Hibernate you'll have to define the non-default-schema in the mapping.
We have a need coming up in an application where the following is true:
A web page uses AJAX to request data from a server.
The specification of the data (e. g. table name) requested from the server will not be known until run-time.
The configuration of the data view is itself data-driven, and configurable by an administrator.
Data updates and inserts must be supported, not just views.
Prototyping this was very easy - we could pass in the appropriate information (table name, changeset, whatever) to a generic data service that just did what it was told (using JSON as the data storage mechanism). The data service could do basic validation on the parameters to ensure the current user can perform the requested operation (read the data, insert a row, read the row).
The issue we have now that we are looking to doing this is a secure production manner, and the idea of passing table names and column names is frightening. Everything we think of to deal with this devolves into trusting the client in some significant way, or seems to involve substantial bookkeeping on the server. For example:
User requests a viewing page.
The server notes the table name and saves it server side with a request ID
The server notes the column names and saves them, replacing them with "col1, col2", etc., and stores the mapping with the request ID data.
The client page sends the request ID to the service, which looks up the server storage by ID
The service returns col1, col2, etc.
This would work, we think, but feels very messy.
Does anyone have experience with this kind of problem and can offer a solution?
Do you need to give them access to raw tables?
Perhaps you can go meta, and make a meta-table that stores the tabular data in a secure manner (ie, only the system knows the table/schema, but the user's concept of schema/table are just abstractions that all map back to the same schema/table)...
Again, more information is needed as to what can be abstracted. Allowing DDL operations by the end-users is asking for trouble, as you rightfully assessed, and I would just abstract that so that "DDL" becomes DML.
However, mapping actual SQL that is written against this data would be much more difficult to abstract, if that is a requirement.
If I had to expose back-end information to end customers, I'd probably hide the actual physical representation using meta-data that would remap table names and columns to more user-friendly text, that would also enable me to provide views on the tables that are a bit more advanced than plain table / column names... As properly modeling associations between tables and so on...