Question

username – revoke select to database.Person

I set

GRANT SELECT (id) ON database.Person TO 'username'@'localhost'

not is work ->

SELECT secret FROM Person  // Good!

not is work ->

SELECT id FROM Person WHERE secret = 1  // BAD!

I need that would SELECT id FROM Person WHERE secret = 1 is worked!

Answer 1

I’m not sure that I’m understanding the question correctly, but it seems to be asking for the ability to restrict the person selecting data from the Persons table so that they cannot see the value in the Secret column, but they should be allowed to use the Secret column in the interior of the query (in the WHERE clause, etc).

CREATE TABLE Person
(
    Id      ...,
    Secret  ...,
    ...
);
REVOKE ALL ON Person FROM PUBLIC;
GRANT SELECT(id) ON Person TO SomeOne;

So, if my interpretation is correct, when SomeOne selects data:

SELECT Id     FROM Person;    -- Works (as required)
SELECT Secret FROM Person;    -- Fails (as required)
SELECT Id
  FROM Person
 WHERE Secret = 1;            -- Fails (but we want it to work)

SQL does not allow that, and for good reason. Basically, if you can condition query results on Secret, you can determine the value of Secret with repeated queries, so what is supposed to be secret does not remain a secret. It is very easy to leak information.

Looking at the query that fails but “shouldn’t”…from its results, you know that every Id returned has the Secret value of 1, so for those Id values, the Secret is no longer secret.

If you look into Statistical Databases, where you’re only allowed to search on aggregate data, you find there are things called Unique Trackers which basically allow you to identify the characteristics of one person, even if you’re only allowed to see aggregate (SUM, COUNT, …) values in the result sets. This is a more complex scenario than you’re facing (but a fascinating one). C J Date’s (long out of print) “Introduction to Database Systems, Vol II” has a discussion of Statistical Database and Unique Trackers. (Google search on ‘statistical database unique tracker’ reveals useful looking information that is more accessible.)

So, if I’ve understood what is desired, I believe the desire is misguided — and the SQL standard does not permit what you seek.

Are there any workarounds?

If the query can be built into a view, the person creating the view can access the underlying detail data and grant access to the view, but the people using the view cannot execute the raw query; this might give you protection you seek. Similar comments apply to stored procedures and allow the query to be parameterized better.