0

ユーザー名 - データベースへの選択を取り消します。

設定しました

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列の値が表示されないようにする機能を求めているようですが、許可する必要がありますクエリの内部（WHERE句など）でSecret列を使用します。

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はそれを許可していません、そして正当な理由があります。基本的に、シークレットでクエリ結果を条件付けできる場合は、クエリを繰り返すことでシークレットの値を決定できるため、シークレットであると想定されるものがシークレットのままになることはありません。情報漏えいは非常に簡単です。

失敗したが「すべきではない」クエリを見ると...その結果から、返されるすべてのIdのシークレット値が1であることがわかります。したがって、これらのId値の場合、シークレットはシークレットではなくなります。

集合体データの検索のみが許可されている統計データベースを調べると、集合体（結果セットのSUM、COUNT、...）値。これはあなたが直面しているよりも複雑なシナリオです（しかし魅力的なシナリオです）。CJ Dateの（長い間印刷されていない）「Introductionto Database Systems、Vol II」では、統計データベースと一意のトラッカーについて説明しています。（「統計データベースの一意のトラッカー」でのGoogle検索により、よりアクセスしやすい便利な情報が明らかになります。）

ですから、私が何が望まれているのかを理解していれば、その欲求は誤った方向に進んでいると思います—そしてSQL標準はあなたが求めるものを許可していません。

回避策はありますか？

クエリをビューに組み込むことができる場合、ビューを作成する人は基になる詳細データにアクセスしてビューへのアクセスを許可できますが、ビューを使用する人は生のクエリを実行できません。これはあなたが求める保護を与えるかもしれません。同様のコメントがストアドプロシージャに適用され、クエリをより適切にパラメータ化できるようになります。

于 2010-12-25T19:50:49.483 に答える
0

「シークレット」列へのアクセスを許可していないため、これを実行することは不可能です。プログラマーがシークレットを読み取れるようにする必要があります。その場合、あなたは彼に秘密の列へのアクセスを許可する必要があります。

シークレット列へのアクセスを許可したくない場合は、WHERE句も許可しないでください。二分探索を使用して、秘密の実際の値を見つけることが可能です。SELECTを実行し、毎回何かが返されるかどうかを確認して、繰り返します。

于 2010-12-25T19:47:20.520 に答える