Thread: Re: Large object security
would'nt it be much better to expand pg_largeobject to have another column "src_oid" (or similar), containing the OID ofthe referencing table from pg_class, and when accessing large objects take the privilieges from the referencing class? -----Ursprüngliche Nachricht----- Von: Damon Cokenias [mailto:lists@mtn-palace.com] Gesendet: Freitag, 19. April 2002 11:04 An: pgsql-hackers Betreff: [HACKERS] Large object security 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 timeto write a patch, but know far to little about postgres internals and history to just dive in. Has there been any discussionon this list about what this feature should be or how it might be implemented? I saw a passing reference to "LOBLOCATORs" 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 permissionswould 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 rightOID. 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
"Mario Weilguni" <mario.weilguni@icomedias.com> writes:
> would'nt it be much better to expand pg_largeobject to have another
> column "src_oid" (or similar), containing the OID of the referencing
> table from pg_class,
What referencing table? The existing LO implementation has no idea
where you are keeping the reference(s). Nor is there any assumption
that there's just one link to the LO.
regards, tom lane
At 12:11 PM +0200 4/19/02, Mario Weilguni wrote: >would'nt it be much better to expand pg_largeobject to have another column "src_oid" (or similar), containing the OID ofthe referencing table from pg_class, and when accessing large objects take the privilieges from the referencing class? It's possible that several tables could reference the same object. And besides, I don't think postgres can tell the differencebetween a column that contains a large object id and a plain old integer. Also, I don't think table-level permissions are flexible enough to be truly useful. What if I want certain objects to bevisible only to certain users, but I want all objects to be referenced from the same table? I can enforce row-level securityon the table with a view. I'd like the same level of flexibility for large objects. Another thought: What if I want to restrict access to large objects based on size or timestamp? -Damon
The problem with this is that the existing functionality of LOs allows you to share a single LO across multiple tables. There may not be a single source, but multiple. Since LOs just use an OID as a FK to the LO, you can store that OID in multiple different tables. --Barry Mario Weilguni wrote: > would'nt it be much better to expand pg_largeobject to have another column "src_oid" (or similar), containing the OID ofthe referencing table from pg_class, and when accessing large objects take the privilieges from the referencing class? > > -----Ursprüngliche Nachricht----- > Von: Damon Cokenias [mailto:lists@mtn-palace.com] > Gesendet: Freitag, 19. April 2002 11:04 > An: pgsql-hackers > Betreff: [HACKERS] Large object security > > > 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 thetime to write a patch, but know far to little about postgres internals and history to just dive in. Has there been anydiscussion 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 permissionswould 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 theright OID. Ideally, users without permission would not know there were objects in the database they were not allowedto see. > > I can also imagine a security scheme that uses rule/trigger syntax to give the user a hook to provide her own securityfunctions. I haven't thought that through, though. > > Any thoughts? > > > -Damon > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >