Large object security

From: Damon Cokenias <lists(at)mtn-palace(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Large object security
Date: 2002-04-19 09:03:38
Message-ID: p04310104b8e5809e0001@[10.0.1.9]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

I see there's a TODO item for large object security, it's a feature I'd really like to see. I'm willing to put in the time to write a patch, but know far to little about postgres internals and history to just dive in. Has there been any discussion on this list about what this feature should be or how it might be implemented? I saw a passing reference to "LOB LOCATORs" in the list archives, but that was all.

What's a LOB LOCATOR ?

What about giving each large object its own permission flags? ex:

GRANT SELECT ON LARGE OBJECT 10291 TO USER webapp;
GRANT SELECT, DELETE, UPDATE ON LARGE OBJECT 10291 TO USER admin;

Default permission flags (and INSERT permissions) would be set at the table level. All objects without specific permissions would use the table rules. This allows for backward compatibility and convenience.

I think per-object security is important. A user shouldn't be able to get at another user's data just by guessing the right OID. Ideally, users without permission would not know there were objects in the database they were not allowed to see.

I can also imagine a security scheme that uses rule/trigger syntax to give the user a hook to provide her own security functions. I haven't thought that through, though.

Any thoughts?

-Damon

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maarten.Boekhold 2002-04-19 09:27:05 Re: Index Scans become Seq Scans after VACUUM ANALYSE
Previous Message Andreas Scherbaum 2002-04-19 08:13:30 Re: new food for the contrib/ directory