0

用户名 - 撤销对 database.Person 的选择

我设置

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

不是工作->

SELECT secret FROM Person  // Good!

不是工作->

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

我需要那会SELECT id FROM Person WHERE secret = 1奏效！

4

2 回答 2

4

我不确定我是否正确理解了这个问题，但它似乎要求能够限制从 Persons 表中选择数据的人，以便他们看不到 Secret 列中的值，但应该允许他们使用查询内部的 Secret 列（在 WHERE 子句等中）。

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

所以，如果我的解释是正确的，当 SomeOne 选择数据时：

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 不允许这样做，这是有充分理由的。基本上，如果您可以对 Secret 的查询结果进行条件化，您可以通过重复查询来确定 Secret 的值，因此应该是秘密的东西不会仍然是秘密。信息泄露非常容易。

查看失败但“不应该”的查询...从其结果中，您知道返回的每个 Id 的 Secret 值都是 1，因此对于这些 Id 值，Secret 不再是秘密。

如果您查看统计数据库，您只能在其中搜索聚合数据，您会发现有一些称为 Unique Trackers 的东西，它基本上可以让您识别一个人的特征，即使您只被允许查看聚合数据（ SUM, COUNT, ...) 结果集中的值。这是一个比您所面临的更复杂的情况（但令人着迷）。CJ Date 的（长期绝版）“数据库系统简介，第二卷”讨论了统计数据库和唯一跟踪器。（“统计数据库唯一跟踪器”上的谷歌搜索显示了更易于访问的有用信息。）

所以，如果我理解了想要什么，我相信这个愿望是错误的——SQL 标准不允许你寻求什么。

有什么解决方法吗？

如果可以将查询构建到视图中，则创建视图的人可以访问底层详细数据并授予对视图的访问权限，但使用视图的人无法执行原始查询；这可能会给您寻求的保护。类似的注释适用于存储过程并允许更好地参数化查询。

于 2010-12-25T19:50:49.483 回答
0

这是不可能的，因为您不允许访问“秘密”列。要么您希望程序员能够阅读 Secret。在这种情况下，您应该授予他访问 Secret 列的权限。

如果您不想允许访问 Secret 列，那么您也不应该允许 WHERE 子句。使用二分查找，可以找出 Secret 的实际值。只需执行 SELECT 并检查它是否每次都返回任何内容，然后重复。

于 2010-12-25T19:47:20.520 回答