KaiGai Kohei wrote:
> Apart from SELinux, it is quite natural to apply any access
> controls on binary data. If we could not have any valid access
> controls, users will not want to store their sensitive
> information, such as confidential PDF files, as a large object.
Absolutely. The histori
Jaime Casanova wrote:
> On Sun, Dec 6, 2009 at 11:19 PM, Greg Smith wrote:
>> I just looked over the latest version of this patch and it seems to satisfy
>> all the issues suggested by the initial review. This looks like it's ready
>> for a committer from a quality perspective and I'm going to ma
On Sun, Dec 6, 2009 at 11:19 PM, Greg Smith wrote:
> I just looked over the latest version of this patch and it seems to satisfy
> all the issues suggested by the initial review. This looks like it's ready
> for a committer from a quality perspective and I'm going to mark it as such.
>
yes. i ha
Greg Smith wrote:
> I just looked over the latest version of this patch and it seems to
> satisfy all the issues suggested by the initial review. This looks like
> it's ready for a committer from a quality perspective and I'm going to
> mark it as such.
Thanks for your efforts.
> I have a gue
I just looked over the latest version of this patch and it seems to
satisfy all the issues suggested by the initial review. This looks like
it's ready for a committer from a quality perspective and I'm going to
mark it as such.
I have a guess what some of the first points of discussion are go
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>
>>> creating template1 database in
>>> /home/postgres/pg_releases/pgsql/src/test/regress/./tmp_check/data/base/1
>>> ... TRAP: FailedAssertion("!(reln->md_fd[forkNum] == ((void *)0))",
>>> File: "md.c", Line: 254)
>>> child process was terminated by
KaiGai Kohei wrote:
> > creating template1 database in
> > /home/postgres/pg_releases/pgsql/src/test/regress/./tmp_check/data/base/1
> > ... TRAP: FailedAssertion("!(reln->md_fd[forkNum] == ((void *)0))",
> > File: "md.c", Line: 254)
> > child process was terminated by signal 6: Aborted
>
> I c
Jaime Casanova wrote:
> 2009/11/12 KaiGai Kohei :
>> The attached patch is a revised version of large object privileges
>> based on the feedbacks at the last commit fest.
>>
>
> please update the patch, it's giving an error when 'make check' is
> trying to "create template1" in initdb:
>
> creati
Robert Haas wrote:
I agree that search and replace isn't that hard, but I don't find the
proposed construction awkward, and we have various uses of it in the
docs already. Actually the COPY one is not quite clear whether it
means <= 7.3 or < 7.3.
Yeah, I wouldn't have suggested it if it made
On Thu, Dec 3, 2009 at 3:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> I agree that search and replace isn't that hard, but I don't find the
>> proposed construction awkward, and we have various uses of it in the
>> docs already. Actually the COPY one is not quite clear whether it
>> means <=
Robert Haas writes:
> I agree that search and replace isn't that hard, but I don't find the
> proposed construction awkward, and we have various uses of it in the
> docs already. Actually the COPY one is not quite clear whether it
> means <= 7.3 or < 7.3. I think we're just aiming for consistenc
On Thu, Dec 3, 2009 at 2:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith wrote:
>>> In this particular example, it's bad form because it's even possible that
>>> 8.5 will actually be 9.0. You don't want to refer to a version number that
>>> doesn't eve
Robert Haas writes:
> On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith wrote:
>> In this particular example, it's bad form because it's even possible that
>> 8.5 will actually be 9.0. You don't want to refer to a version number that
>> doesn't even exist for sure yet, lest it leave a loose end that ne
On Thu, Dec 3, 2009 at 1:23 PM, Greg Smith wrote:
> Robert Haas wrote:
> On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova
> wrote:
>
> This manual will be specific for 8.5 so i think all mentions to the
> version should be removed
>
> Not sure I agree on this point. We have similar mentions elsew
Robert Haas wrote:
On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova
wrote:
This manual will be specific for 8.5 so i think all mentions to the
version should be removed
Not sure I agree on this point. We have similar mentions elsewhere.
In this particular example, it's bad form bec
On Thu, Dec 3, 2009 at 12:49 PM, Jaime Casanova
wrote:
> This manual will be specific for 8.5 so i think all mentions to the
> version should be removed
Not sure I agree on this point. We have similar mentions elsewhere.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
2009/11/12 KaiGai Kohei :
> The attached patch is a revised version of large object privileges
> based on the feedbacks at the last commit fest.
>
please update the patch, it's giving an error when 'make check' is
trying to "create template1" in initdb:
creating template1 database in
/home/postgr
2009/10/15 Heikki Linnakangas :
> KaiGai Kohei wrote:
>> I have to focus on my patches with highest priority in CommitFest,
>> but it may be possible to help reviewing the proposed patches in
>> the off-fest season. It is illegal/undesirable for the process?
>
> No, that's absolutely fine. During c
KaiGai Kohei wrote:
> I have to focus on my patches with highest priority in CommitFest,
> but it may be possible to help reviewing the proposed patches in
> the off-fest season. It is illegal/undesirable for the process?
No, that's absolutely fine. During commitfests patch review is needed
the mo
Robert Haas wrote:
> 2009/10/14 KaiGai Kohei :
>> Robert Haas wrote:
>>> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
KaiGai Kohei writes:
> Tom Lane wrote:
>> The most serious problem is that you ripped out myLargeObjectExists(),
>> apparently because you didn't understand
2009/10/14 KaiGai Kohei :
> Robert Haas wrote:
>> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
>>> KaiGai Kohei writes:
Tom Lane wrote:
> The most serious problem is that you ripped out myLargeObjectExists(),
> apparently because you didn't understand what it's there for. The r
Robert Haas wrote:
> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
>> KaiGai Kohei writes:
>>> Tom Lane wrote:
The most serious problem is that you ripped out myLargeObjectExists(),
apparently because you didn't understand what it's there for. The reason
it's there is to ensur
Tom Lane wrote:
>> The newer basis is same as other database objects, such as functions.
>> But why pg_dump performs correctly for these database objects?
>
> The reason pg_dump works reasonably well is that it takes locks on
> tables, and the other objects it dumps (such as functions) have
> indi
On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote:
> KaiGai Kohei writes:
>> Tom Lane wrote:
>>> The most serious problem is that you ripped out myLargeObjectExists(),
>>> apparently because you didn't understand what it's there for. The reason
>>> it's there is to ensure that pg_dump runs don't
KaiGai Kohei writes:
> Tom Lane wrote:
>> The most serious problem is that you ripped out myLargeObjectExists(),
>> apparently because you didn't understand what it's there for. The reason
>> it's there is to ensure that pg_dump runs don't fail. pg_dump is expected
>> to produce a consistent dum
Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached patch is the revised one for largeobejct access controls,
>> because it conflicted to the "GRANT/REVOKE ON ALL xxx IN SCHEMA".
>
> I started to look through this patch with the hope of committing it, but
> found out that it's not really ready
KaiGai Kohei writes:
> The attached patch is the revised one for largeobejct access controls,
> because it conflicted to the "GRANT/REVOKE ON ALL xxx IN SCHEMA".
I started to look through this patch with the hope of committing it, but
found out that it's not really ready.
The most serious proble
The attached patch is the revised one for largeobejct access controls,
because it conflicted to the "GRANT/REVOKE ON ALL xxx IN SCHEMA".
No other changes are here.
Please apply this one, instead of the older revision (r2354).
Thanks,
$ diffstat /home/kaigai/RPMS/SOURCES/sepgsql-02-blob-8.5devel-
Tom Lane wrote:
> KaiGai Kohei writes:
>> I rebased the largeobject access controls patch to the CVS HEAD
>> because of the patch confliction to the default ACL patch.
>
> Quick comment on this --- I think that using a syscache for large
> objects is probably not a good idea. There is no provisi
Alvaro Herrera wrote:
KaiGai Kohei escribió:
I added a syscache entry for pg_largeobject_metadata, not pg_largeobject
which contains data chunks. The pg_largeobject_metadata is a smaller catalog
than most of system catalogs, such as pg_class.
The point is not the size of the cache entries, bu
KaiGai Kohei escribió:
> I added a syscache entry for pg_largeobject_metadata, not pg_largeobject
> which contains data chunks. The pg_largeobject_metadata is a smaller catalog
> than most of system catalogs, such as pg_class.
The point is not the size of the cache entries, but the number of them
Tom Lane wrote:
> KaiGai Kohei writes:
>> I rebased the largeobject access controls patch to the CVS HEAD
>> because of the patch confliction to the default ACL patch.
>
> Quick comment on this --- I think that using a syscache for large
> objects is probably not a good idea. There is no provisi
KaiGai Kohei writes:
> I rebased the largeobject access controls patch to the CVS HEAD
> because of the patch confliction to the default ACL patch.
Quick comment on this --- I think that using a syscache for large
objects is probably not a good idea. There is no provision in the
catcache code fo
I rebased the largeobject access controls patch to the CVS HEAD
because of the patch confliction to the default ACL patch.
The only difference was a switch-case statement was moved from
shdepDropOwned() to RemoveRoleFromObjectACL(), so we had to
change the point to be patched.
I don't think this
Thanks for your comments.
Jaime Casanova wrote:
> 2009/9/24 KaiGai Kohei :
>> The attached patch is revised from the previous revision at the following
>> points:
>>
>> - The "largeobject_compat_acl" is renamed to "largeobject_check_acl".
>> Its default is on, and turning it off means the largeo
2009/9/24 KaiGai Kohei :
> The attached patch is revised from the previous revision at the following
> points:
>
> - The "largeobject_compat_acl" is renamed to "largeobject_check_acl".
> Its default is on, and turning it off means the largeobject stuff
> performs in compatible mode for the v8.4.
2009/9/24 KaiGai Kohei :
> The attached patch is revised from the previous revision at the following
> points:
Jaime,
Do you think this is Ready for Committer review at this point? If so,
please mark it that way; otherwise, what do you think are the
outstanding issues?
...Robert
--
Sent via
The attached patch is revised from the previous revision at the following
points:
- The "largeobject_compat_acl" is renamed to "largeobject_check_acl".
Its default is on, and turning it off means the largeobject stuff
performs in compatible mode for the v8.4.x or prior releases.
- Notificatio
Jaime Casanova wrote:
> 2009/9/24 KaiGai Kohei :
>> Example)
>> postgres=# SET SESSION AUTHORIZATION ymj;
>> SET
>> postgres=> SELECT loread(lo_open(16453, x'4'::int), 20);
>> ERROR: permission denied for largeobject 16453
>>
>> postgres=# SET largeobject_compat_acl = on; <
Jaime Casanova wrote:
> 2009/9/23 KaiGai Kohei :
>> Jaime,
>>
>> KaiGai Kohei wrote:
>> | > ALTER LARGE OBJECT is working, but now that we can change the owner of
>> | > a LO we should be able to see who the actual owner is... i mean we
>> | > should add an owner column in \dl for psql (maybe \dl+)
2009/9/24 KaiGai Kohei :
>
> Example)
> postgres=# SET SESSION AUTHORIZATION ymj;
> SET
> postgres=> SELECT loread(lo_open(16453, x'4'::int), 20);
> ERROR: permission denied for largeobject 16453
>
> postgres=# SET largeobject_compat_acl = on; < enables
> compatible mode
>
2009/9/23 KaiGai Kohei :
> Jaime,
>
> KaiGai Kohei wrote:
> | > ALTER LARGE OBJECT is working, but now that we can change the owner of
> | > a LO we should be able to see who the actual owner is... i mean we
> | > should add an owner column in \dl for psql (maybe \dl+) and maybe an
> | > lo_owner()
> Now, I'm revising the patch as follows:
> - pg_largeobject_meta is renamed to pg_largeobject_metadata
> - The GUC of largeobject_compat_dac is renamed to largeobject_compat_acl
> - psql supports \dl to show owner of the largeobject
> - add documentation for the GUC, and add it to the postgresql.c
Robert Haas wrote:
> 2009/9/23 KaiGai Kohei :
>> Now, I'm revising the patch as follows:
>> - pg_largeobject_meta is renamed to pg_largeobject_metadata
>> - The GUC of largeobject_compat_dac is renamed to largeobject_compat_acl
>> - psql supports \dl to show owner of the largeobject
>> - add docume
2009/9/23 KaiGai Kohei :
> Now, I'm revising the patch as follows:
> - pg_largeobject_meta is renamed to pg_largeobject_metadata
> - The GUC of largeobject_compat_dac is renamed to largeobject_compat_acl
> - psql supports \dl to show owner of the largeobject
> - add documentation for the GUC, and a
Jaime,
KaiGai Kohei wrote:
| > ALTER LARGE OBJECT is working, but now that we can change the owner of
| > a LO we should be able to see who the actual owner is... i mean we
| > should add an owner column in \dl for psql (maybe \dl+) and maybe an
| > lo_owner() function.
|
| I would like to buy you
On Tue, Sep 22, 2009 at 12:53 PM, Robert Haas wrote:
> On Tue, Sep 22, 2009 at 1:29 PM, Jaime Casanova
> wrote:
>> have anyone better ideas about the name? if not, then go with
>> pg_largeobject_meta
>
> I don't think there's anything wrong with calling it metadata. That
> seems to leave the doo
On Tue, Sep 22, 2009 at 1:29 PM, Jaime Casanova
wrote:
> have anyone better ideas about the name? if not, then go with
> pg_largeobject_meta
I don't think there's anything wrong with calling it metadata. That
seems to leave the door open to future things we might want to do,
without restricting
On Tue, Sep 22, 2009 at 7:23 AM, KaiGai Kohei wrote:
>
>> another one, is it possible for us to have a CREATE LARGE OBJECT
>> statement?
>> the reason for this is:
>> 1) it is a little ugly to use the OID in ALTER/GRANT/REVOKE
>> statements, in a create statement we can assign a name to the LO
>>
Jaime, Thanks for your reviewing.
Jaime Casanova wrote:
2009/9/6 KaiGai Kohei :
The attached patch is an update of largeobject access controls.
it applies fine (just 3 succeded hunks), compiles and passes
regression tests...
ALTER LARGE OBJECT is working, but now that we can change the owne
2009/9/6 KaiGai Kohei :
> The attached patch is an update of largeobject access controls.
>
it applies fine (just 3 succeded hunks), compiles and passes
regression tests...
ALTER LARGE OBJECT is working, but now that we can change the owner of
a LO we should be able to see who the actual owner is
On Fri, Sep 18, 2009 at 8:29 PM, Stephen Frost wrote:
> Jamie,
>
> How is the review for this coming? Do you have any thoughts regarding
> the new GUC?
>
Hi, sorry... these have been hard days... i'm just starting reviewing
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
As
Jamie,
* Robert Haas (robertmh...@gmail.com) wrote:
> Jaime Casanova
> - Largeobject access controls
How is the review for this coming? Do you have any thoughts regarding
the new GUC?
Thanks,
Stephen
signature.asc
Description: Digital signature
The attached patch is an update of largeobject access controls.
It adds a new guc variable to turn on/off compatible behavior in
largeobejct access controls.
largeobject_compat_dac = [on | off] (default: off)
If the variable is turned on, all the new access control features
on largeobjects are
Robert Haas wrote:
> 2009/9/3 KaiGai Kohei :
>> KaiGai Kohei wrote:
>>> Alvaro Herrera wrote:
Tom Lane wrote:
> KaiGai Kohei writes:
>> BTW, currently, the default ACL of largeobject allows anything for owner
>> and nothing for world. Do you have any comment for the default behavi
2009/9/3 KaiGai Kohei :
> KaiGai Kohei wrote:
>> Alvaro Herrera wrote:
>>> Tom Lane wrote:
KaiGai Kohei writes:
> BTW, currently, the default ACL of largeobject allows anything for owner
> and nothing for world. Do you have any comment for the default behavior?
Mph. I think the
KaiGai Kohei wrote:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei writes:
BTW, currently, the default ACL of largeobject allows anything for owner
and nothing for world. Do you have any comment for the default behavior?
>>> Mph. I think the backlash will be too great. You
Alvaro Herrera wrote:
> Tom Lane wrote:
>> KaiGai Kohei writes:
>>> BTW, currently, the default ACL of largeobject allows anything for owner
>>> and nothing for world. Do you have any comment for the default behavior?
>> Mph. I think the backlash will be too great. You have to leave the
>> defau
Tom Lane wrote:
> KaiGai Kohei writes:
> > BTW, currently, the default ACL of largeobject allows anything for owner
> > and nothing for world. Do you have any comment for the default behavior?
>
> Mph. I think the backlash will be too great. You have to leave the
> default behavior the same as
The attached patch is the revised version of largeobject access controls.
It reverts pg_largeobject system catalog, and adds new pg_largeobject_meta
system catalog to store the owner identifier and its ACLs.
The definition of pg_largeobject_meta:
#define LargeObjectMetaRelationId 2336
CATA
KaiGai Kohei wrote:
> BTW, currently, the default ACL of largeobject allows anything for owner
> and nothing for world. Do you have any comment for the default behavior?
Backwards compatibility would say that the world should be able to at
least read the object.
--
Alvaro Herrera
KaiGai Kohei writes:
> BTW, currently, the default ACL of largeobject allows anything for owner
> and nothing for world. Do you have any comment for the default behavior?
Mph. I think the backlash will be too great. You have to leave the
default behavior the same as it is now, ie, world access.
The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT.
It enables to controls whether the user can create a largeobject, or not.
>>> I don't think this is necessary or appropriate.
>
>> What should control privilege to create a new largeobject?
>> Or, it implicitly a
KaiGai Kohei writes:
> Tom Lane wrote:
>> What about DELETE permissions? Should we track that separately from
>> UPDATE?
> PostgreSQL checks ownership of the database object when user tries to
> drop it. This patch also add pg_largeobject_ownercheck() on lo_unlink().
Oh, okay, that will do fine
Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached patch provides access control features on largeobject.
>> This patch adds the ownership and two permissions (SELECT and UPDATE) on
>> largeobjects. The two permissions controls reader and writer accesses to
>> the largeobejcts.
>
> What about
KaiGai Kohei writes:
> The attached patch provides access control features on largeobject.
> This patch adds the ownership and two permissions (SELECT and UPDATE) on
> largeobjects. The two permissions controls reader and writer accesses to
> the largeobejcts.
What about DELETE permissions? Shou
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>
>> The pg_largeobject system catalog is reworked to manage its metadata.
>>
>> CATALOG(pg_largeobject,2613)
>> {
>> Oid loowner;/* OID of the owner */
>> Oid lochunk;/* OID of the data chunks */
>>
KaiGai Kohei wrote:
> The pg_largeobject system catalog is reworked to manage its metadata.
>
> CATALOG(pg_largeobject,2613)
> {
> Oid loowner;/* OID of the owner */
> Oid lochunk;/* OID of the data chunks */
> aclitem loacl[1]; /*
68 matches
Mail list logo
