Обсуждение: Follow-up OpenOffice and Postgres 7.3.2
I finally tracked down the problem. You have to use the GRANT command to set privileges on your table. Postgres assumes the table owner has all rights but does do not write that info into the access control list of pg_class. It would seem the JDBC driver looks to pg_class for information on permissions. Using GRANT makes the permissions explicit and therefore makes the JDBC driver happy.
Adrian Klaver <aklaver@attbi.com> writes:
> I finally tracked down the problem. You have to use the GRANT command to set
> privileges on your table. Postgres assumes the table owner has all rights but
> does do not write that info into the access control list of pg_class. It
> would seem the JDBC driver looks to pg_class for information on permissions.
Hm. The backend treats NULL in pg_class.relacl as meaning the default
permissions (owner = all, everyone else = none). I wonder whether jdbc
gets that right?
regards, tom lane
The driver doesn't do anything when a "create table foo ..." is executed, and there is no api for modifying the user permissions ?? Dave On Wed, 2003-03-19 at 00:53, Tom Lane wrote: > Adrian Klaver <aklaver@attbi.com> writes: > > I finally tracked down the problem. You have to use the GRANT command to set > > privileges on your table. Postgres assumes the table owner has all rights but > > does do not write that info into the access control list of pg_class. It > > would seem the JDBC driver looks to pg_class for information on permissions. > > Hm. The backend treats NULL in pg_class.relacl as meaning the default > permissions (owner = all, everyone else = none). I wonder whether jdbc > gets that right? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Dave Cramer <Dave@micro-automation.net>
I haven't been able to recreate any of this??? When a table is made, it automatically is owned by the owner of the connection, so it should have write privleges by the owner??? I did note that oo defaults to trying to use the connection owners name for schema, I forced it to public when I created my tables. Does that make a difference ? I did find one more thing though oo tries to create index's using the following syntax; which won't work CREATE INDEX "id_idx" ON "public"."ootable" ( "id" DESC) Dave On Wed, 2003-03-19 at 04:36, Dave Cramer wrote: > The driver doesn't do anything when a "create table foo ..." is > executed, and there is no api for modifying the user permissions ?? > > Dave > On Wed, 2003-03-19 at 00:53, Tom Lane wrote: > > Adrian Klaver <aklaver@attbi.com> writes: > > > I finally tracked down the problem. You have to use the GRANT command to set > > > privileges on your table. Postgres assumes the table owner has all rights but > > > does do not write that info into the access control list of pg_class. It > > > would seem the JDBC driver looks to pg_class for information on permissions. > > > > Hm. The backend treats NULL in pg_class.relacl as meaning the default > > permissions (owner = all, everyone else = none). I wonder whether jdbc > > gets that right? > > > > regards, tom lane > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Dave Cramer <Dave@micro-automation.net>
I created a table from within OO 1.01 and had no write privileges. The first problem is that OO will not grant editing rights to a table without a primary key. As you found out you cannot create an index from within OO. The second problem is that creating a table in OO does nothing to the relacl column in pg_class. As Tom wrote a null value is considered by Postgres to be full permissions for the owner. The JDBC driver sees things differently and would not allow me to edit until I used GRANT to populate relacl with permissions. The third problem is that disconnecting and reconnecting from within OO did not catch the change. The only way to make the change apparent was to shut OO down and then reopen it. There must be caching of values going on behind the scenes. On Wednesday 19 March 2003 02:01 am, Dave Cramer wrote: > I haven't been able to recreate any of this??? > > When a table is made, it automatically is owned by the owner of the > connection, so it should have write privleges by the owner??? > > I did note that oo defaults to trying to use the connection owners name > for schema, I forced it to public when I created my tables. Does that > make a difference ? > > I did find one more thing though > > oo tries to create index's using the following syntax; which won't work > > CREATE INDEX "id_idx" ON "public"."ootable" ( "id" DESC) > > Dave > > On Wed, 2003-03-19 at 04:36, Dave Cramer wrote: > > The driver doesn't do anything when a "create table foo ..." is > > executed, and there is no api for modifying the user permissions ?? > > > > Dave > > > > On Wed, 2003-03-19 at 00:53, Tom Lane wrote: > > > Adrian Klaver <aklaver@attbi.com> writes: > > > > I finally tracked down the problem. You have to use the GRANT command > > > > to set privileges on your table. Postgres assumes the table owner has > > > > all rights but does do not write that info into the access control > > > > list of pg_class. It would seem the JDBC driver looks to pg_class for > > > > information on permissions. > > > > > > Hm. The backend treats NULL in pg_class.relacl as meaning the default > > > permissions (owner = all, everyone else = none). I wonder whether jdbc > > > gets that right? > > > > > > regards, tom lane > > > > > > ---------------------------(end of > > > broadcast)--------------------------- TIP 1: subscribe and unsubscribe > > > commands go to majordomo@postgresql.org
First off my environment is redhat 8.0, oo 1.0.1 On Wed, 2003-03-19 at 09:39, Adrian Klaver wrote: > I created a table from within OO 1.01 and had no write privileges. The first > problem is that OO will not grant editing rights to a table without a primary > key. This is not the case in my environment > As you found out you cannot create an index from within OO. This is true > The second > problem is that creating a table in OO does nothing to the relacl column in > pg_class. As Tom wrote a null value is considered by Postgres to be full > permissions for the owner. > The JDBC driver sees things differently and would > not allow me to edit until I used GRANT to populate relacl with permissions. the driver does not interfere in this?? > The third problem is that disconnecting and reconnecting from within OO did > not catch the change. The only way to make the change apparent was to shut OO > down and then reopen it. There must be caching of values going on behind the > scenes. The connection was not released apparently? > On Wednesday 19 March 2003 02:01 am, Dave Cramer wrote: > > I haven't been able to recreate any of this??? > > > > When a table is made, it automatically is owned by the owner of the > > connection, so it should have write privleges by the owner??? > > > > I did note that oo defaults to trying to use the connection owners name > > for schema, I forced it to public when I created my tables. Does that > > make a difference ? > > > > I did find one more thing though > > > > oo tries to create index's using the following syntax; which won't work > > > > CREATE INDEX "id_idx" ON "public"."ootable" ( "id" DESC) > > > > Dave > > > > On Wed, 2003-03-19 at 04:36, Dave Cramer wrote: > > > The driver doesn't do anything when a "create table foo ..." is > > > executed, and there is no api for modifying the user permissions ?? > > > > > > Dave > > > > > > On Wed, 2003-03-19 at 00:53, Tom Lane wrote: > > > > Adrian Klaver <aklaver@attbi.com> writes: > > > > > I finally tracked down the problem. You have to use the GRANT command > > > > > to set privileges on your table. Postgres assumes the table owner has > > > > > all rights but does do not write that info into the access control > > > > > list of pg_class. It would seem the JDBC driver looks to pg_class for > > > > > information on permissions. > > > > > > > > Hm. The backend treats NULL in pg_class.relacl as meaning the default > > > > permissions (owner = all, everyone else = none). I wonder whether jdbc > > > > gets that right? > > > > > > > > regards, tom lane > > > > > > > > ---------------------------(end of > > > > broadcast)--------------------------- TIP 1: subscribe and unsubscribe > > > > commands go to majordomo@postgresql.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Dave Cramer <Dave@micro-automation.net>
Adrian, There was a bug in the driver in dealing with default permissions for the owner. I fixed that bug last night and posted a new build for 7.3 (build 109) on the website. Give this a try. thanks, --Barry Adrian Klaver wrote: > I created a table from within OO 1.01 and had no write privileges. The first > problem is that OO will not grant editing rights to a table without a primary > key. As you found out you cannot create an index from within OO. The second > problem is that creating a table in OO does nothing to the relacl column in > pg_class. As Tom wrote a null value is considered by Postgres to be full > permissions for the owner. The JDBC driver sees things differently and would > not allow me to edit until I used GRANT to populate relacl with permissions. > The third problem is that disconnecting and reconnecting from within OO did > not catch the change. The only way to make the change apparent was to shut OO > down and then reopen it. There must be caching of values going on behind the > scenes. > On Wednesday 19 March 2003 02:01 am, Dave Cramer wrote: > >>I haven't been able to recreate any of this??? >> >>When a table is made, it automatically is owned by the owner of the >>connection, so it should have write privleges by the owner??? >> >>I did note that oo defaults to trying to use the connection owners name >>for schema, I forced it to public when I created my tables. Does that >>make a difference ? >> >>I did find one more thing though >> >>oo tries to create index's using the following syntax; which won't work >> >>CREATE INDEX "id_idx" ON "public"."ootable" ( "id" DESC) >> >>Dave >> >>On Wed, 2003-03-19 at 04:36, Dave Cramer wrote: >> >>>The driver doesn't do anything when a "create table foo ..." is >>>executed, and there is no api for modifying the user permissions ?? >>> >>>Dave >>> >>>On Wed, 2003-03-19 at 00:53, Tom Lane wrote: >>> >>>>Adrian Klaver <aklaver@attbi.com> writes: >>>> >>>>>I finally tracked down the problem. You have to use the GRANT command >>>>>to set privileges on your table. Postgres assumes the table owner has >>>>>all rights but does do not write that info into the access control >>>>>list of pg_class. It would seem the JDBC driver looks to pg_class for >>>>>information on permissions. >>>> >>>>Hm. The backend treats NULL in pg_class.relacl as meaning the default >>>>permissions (owner = all, everyone else = none). I wonder whether jdbc >>>>gets that right? >>>> >>>> regards, tom lane >>>> >>>>---------------------------(end of >>>>broadcast)--------------------------- TIP 1: subscribe and unsubscribe >>>>commands go to majordomo@postgresql.org > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
Finally got around to trying the new build and it works as advertised.
Thank you
Adrian Klaver
On Monday 24 March 2003 08:27 am, Barry Lind wrote:
> Adrian,
>
> There was a bug in the driver in dealing with default permissions for
> the owner. I fixed that bug last night and posted a new build for 7.3
> (build 109) on the website. Give this a try.
>
> thanks,
> --Barry
>
> Adrian Klaver wrote:
> > I created a table from within OO 1.01 and had no write privileges. The
> > first problem is that OO will not grant editing rights to a table without
> > a primary key. As you found out you cannot create an index from within
> > OO. The second problem is that creating a table in OO does nothing to the
> > relacl column in pg_class. As Tom wrote a null value is considered by
> > Postgres to be full permissions for the owner. The JDBC driver sees
> > things differently and would not allow me to edit until I used GRANT to
> > populate relacl with permissions. The third problem is that disconnecting
> > and reconnecting from within OO did not catch the change. The only way
> > to make the change apparent was to shut OO down and then reopen it. There
> > must be caching of values going on behind the scenes.
> >
> > On Wednesday 19 March 2003 02:01 am, Dave Cramer wrote:
> >>I haven't been able to recreate any of this???
> >>
> >>When a table is made, it automatically is owned by the owner of the
> >>connection, so it should have write privleges by the owner???
> >>
> >>I did note that oo defaults to trying to use the connection owners name
> >>for schema, I forced it to public when I created my tables. Does that
> >>make a difference ?
> >>
> >>I did find one more thing though
> >>
> >>oo tries to create index's using the following syntax; which won't work
> >>
> >>CREATE INDEX "id_idx" ON "public"."ootable" ( "id" DESC)
> >>
> >>Dave
> >>
> >>On Wed, 2003-03-19 at 04:36, Dave Cramer wrote:
> >>>The driver doesn't do anything when a "create table foo ..." is
> >>>executed, and there is no api for modifying the user permissions ??
> >>>
> >>>Dave
> >>>
> >>>On Wed, 2003-03-19 at 00:53, Tom Lane wrote:
> >>>>Adrian Klaver <aklaver@attbi.com> writes:
> >>>>>I finally tracked down the problem. You have to use the GRANT command
> >>>>>to set privileges on your table. Postgres assumes the table owner has
> >>>>>all rights but does do not write that info into the access control
> >>>>>list of pg_class. It would seem the JDBC driver looks to pg_class for
> >>>>>information on permissions.
> >>>>
> >>>>Hm. The backend treats NULL in pg_class.relacl as meaning the default
> >>>>permissions (owner = all, everyone else = none). I wonder whether jdbc
> >>>>gets that right?
> >>>>
> >>>> regards, tom lane
> >>>>
> >>>>---------------------------(end of
> >>>>broadcast)--------------------------- TIP 1: subscribe and unsubscribe
> >>>>commands go to majordomo@postgresql.org
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster