5

在 PostgreSQL 中，如何防止任何人（包括超级用户）删除某些特定表？

编辑：哇，我们这里有什么误解吗。假设有一个大型的共享 QA 数据库。有时人们会错误地在其上运行破坏性的东西，例如休眠生成的模式，我正在寻找防止此类错误的方法。

4

5 回答 5

3

任何人（包括超级用户）都不要删除某些特定的表？

相信你的同龄人。

于 2013-06-27T10:24:05.130 回答
3

您可以通过编写一些附加到ProcessUtility_hook. 如果您从未做过这种事情，那将不会是微不足道的，但这是可能的。

另一种选择可能是研究 sepgsql，但我对此没有任何经验。

于 2013-06-27T12:58:46.740 回答
2

超级用户就是这样。如果您不希望他们能够丢弃东西，请不要让他们成为超级用户。

几乎没有必要让用户以超级用户身份运行。当然不是像模式迁移这样的自动化工具。

您的应用程序应以具有所需最低用户权限的用户身份连接。他们不应该拥有他们操作的表，因此他们不能对它们进行架构更改或删除它们。

当您想要更改架构时，请使用对感兴趣的表拥有所有权但不是超级用户的用户运行应用程序。表所有者可以删除和修改表，但只能删除它拥有的表。

如果你真的，真的需要做一些超出标准权限模型的事情，你需要编写一个ProcessUtility_hook. 有关这方面的一些详细信息，请参阅此相关答案。即使这样，超级用户也可以通过加载跳过你的钩子的扩展来绕过它，你只会减慢它们的速度。

不要在生产环境中以超级用户身份运行应用程序。曾经。

有关使用权限模型的更多指导，请参阅有关权限的 PostgreSQL 文档。

于 2013-07-02T07:49:57.303 回答
1

我不认为你能做到这一点。您可能拥有超级超级用户，他们将首先管理所有内容的删除。或者不断地进行备份，因此层次结构的较高成员将始终有可能检索表。

于 2013-06-27T10:25:32.890 回答
0

我不知道这个问题的真正初衷是什么......但很多人似乎都有假设的答案，比如信任你的同行或适当地使用最少权限模型。就个人而言，这完全没有抓住重点，而是用每个人可能已经知道的东西来回答，这并不是特别有用。

所以让我尝试一个我自己的问题+答案：你如何设置安全锁以防止自己或他人不小心做你不应该做的事情？如果您认为这种“不应该发生”，那么我认为您的想象力太狭窄了。或者也许你比我（可能还有很多其他人）更完美。

对于我们其他人来说，这是一个适合我的解决方案。它只是一个小锁，可以放在任何你想要的地方——使用事件触发器。显然，这将由某种超级用户来实现。但关键是它与权限无关，因为它是基于错误而不是基于权限的。

显然，如果生产行为依赖于它，你不应该实现这种东西。只有在有意义的情况下使用才有意义。不要用它来代替应该使用权限解决的问题，也不要用它来破坏你的团队。使用常识 - 个人结果可能会有所不同。


CREATE SCHEMA testst;

CREATE OR REPLACE FUNCTION manual_override_required() RETURNS event_trigger AS
$$
DECLARE
    obj record;
BEGIN
FOR obj IN SELECT * FROM pg_event_trigger_dropped_objects()
LOOP
    RAISE INFO 'object_oid: %, object_type: %', obj.objid, obj.object_type;
    RAISE info '%', obj.object_name;
    IF obj.object_type = 'schema' and obj.object_name = 'testst' THEN
        RAISE EXCEPTION 'You have attempted to DROP something which has been hyper-locked and requires manual override to proceed.';
    END IF;
END LOOP;
END
$$
LANGUAGE plpgsql
;


DROP EVENT TRIGGER IF EXISTS lock_schema;
CREATE EVENT TRIGGER lock_schema
   ON sql_drop
EXECUTE FUNCTION manual_override_required();

DROP SCHEMA testst;

-- produces error: "ERROR: You have attempted to DROP something which has been admin-locked and requires manual override to proceed."


-- To override the admin-lock (you have the permission to do this, it just requires two turns of a key and positive confirmation):

ALTER EVENT TRIGGER lock_schema DISABLE;


DROP SCHEMA testst;
-- now it works!

我如何使用它的一个例子是在自动化工作流程中。我必须每天在开发环境和生产环境之间切换十几次，尽管我已经竖起巨大的旗帜和横幅来提醒自己，但我可以（即）很容易忘记哪个是哪个。删除某些模式在 Prod 中应该是罕见且特殊的事件（因此是主动确认方法的好处），而在开发中我一直在重建它们。如果我在 Dev 中维护与在 Prod 中相同的权限结构（我这样做），那么我将无法解决这个问题。

于 2021-06-01T23:22:25.707 回答