postgres-xc-developers Mailing List for Postgres-XC

>
> If you don't execute SET ROLE on the datanode connections, you would
> continue accessing the data with the connection user who may not have
> enough access rights to access the data.
>
OK, I see, so we need to push down this parameter, but also we need to
maintain the connections alive between coordinator and Datanodes to keep the
session on.

Well, this is a part of the implementation of session parameters.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Hi Michael,
You want to make sure that the user which makes connection to data nodes has
privileges to execute set role on data node. I think, not everyone is
allowed to execute 'set role' using any user name.

On Fri, Apr 1, 2011 at 4:59 PM, Michael Paquier
<mic...@gm...>wrote:

> Just another point. XC is using session user to build pooler connections.
> When you change the current user with set role, the same session
> connections are being used, but access to data or tables is managed by
> Coordinators with current user value.
>
> --
> Thanks,
>
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Best Wishes,
Ashutosh Bapat

On Fri, Apr 1, 2011 at 5:25 PM, Michael Paquier
<mic...@gm...> wrote:
> Hi,
>
> On Fri, Apr 1, 2011 at 8:40 PM, Ashutosh Bapat
> <ash...@en...> wrote:
>>
>> Hi Michael,
>> You want to make sure that the user which makes connection to data nodes
>> has privileges to execute set role on data node. I think, not everyone is
>> allowed to execute 'set role' using any user name.
>
> Yes indeed, it may be necessary to execute also set role on Datanodes,
> but as long as the application only needs to connect to Coordinators,
> executing set role only on the coordinator where session is is not enough?
>
> For the execution of set role, I am not really familiar with that but I
> would think it depends on the rights a role have when it has been defined or
> altered with CREATE/ALTER ROLE.
> On Coordinator, XC uses uses the same protocol as postgres, so I think it
> may be OK to have set role only executed on Coordinator, no?


If you don't execute SET ROLE on the datanode connections, you would
continue accessing the data with the connection user who may not have
enough access rights to access the data.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

Hi,

On Fri, Apr 1, 2011 at 8:40 PM, Ashutosh Bapat <
ash...@en...> wrote:

> Hi Michael,
> You want to make sure that the user which makes connection to data nodes
> has privileges to execute set role on data node. I think, not everyone is
> allowed to execute 'set role' using any user name.
>
Yes indeed, it may be necessary to execute also set role on Datanodes,
but as long as the application only needs to connect to Coordinators,
executing set role only on the coordinator where session is is not enough?

For the execution of set role, I am not really familiar with that but I
would think it depends on the rights a role have when it has been defined or
altered with CREATE/ALTER ROLE.
On Coordinator, XC uses uses the same protocol as postgres, so I think it
may be OK to have set role only executed on Coordinator, no?

~$ psql -U toto -p 5452 template1
psql (9.0.3)
template1=> set role ioltas; -- superuser
ERROR:  permission denied to set role "ioltas"
template1=> select usename,usesuper from pg_user;
 usename | usesuper
---------+----------
 ioltas  | t
 toto    | f
(2 rows)
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Just another point. XC is using session user to build pooler connections.
When you change the current user with set role, the same session connections
are being used, but access to data or tables is managed by Coordinators with
current user value.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

> Are you saying only superusers can make password-less login ? I doubt
> if its really the case or it has more to do with the pg_hba.conf
> setting. Can you please check ?
>
No, normal users also can make a normal login. I checked that.

> Another thing I am worried about is that this would increase the
> number of connections to the data node because there will be a
> separate connection for each user. Did we check if we can make use of
> SET ROLE facility to use a single connection for multiple users ?
>
Yeah, exactly, if users log in with different user names the database pool
will be different for each user. This increases the number of connections to
datanodes.

Well, I didn't make any checks for SET ROLE when finishing the
implementation, but it looks to work correctly.
ioltas@oltania:~/pgsql$ psql template1
psql (9.0.3)
Type "help" for help.
template1=# create table aa (a int);
CREATE TABLE
template1=# set role toto;
SET
template1=> select * from aa;
ERROR:  permission denied for relation aa
template1=> set role ioltas;
SET
template1=# select * from aa;
 a
---
(0 rows)

SET has only effects on Coordinator, but also GRANT is effective on
Coordinator so permissions are not a problem. And both users use the same
connections. I checked.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Hi Michael,

Are you saying only superusers can make password-less login ? I doubt
if its really the case or it has more to do with the pg_hba.conf
setting. Can you please check ?

Another thing I am worried about is that this would increase the
number of connections to the data node because there will be a
separate connection for each user. Did we check if we can make use of
SET ROLE facility to use a single connection for multiple users ?

Thanks,
Pavan

On Fri, Apr 1, 2011 at 12:22 PM, Koichi Suzuki <koi...@gm...> wrote:
> Okay.   Only a superuser can issue this.   You can commit this patch.
>
> In the future, normal user may want to clean connection assigned to
> the current coordinator backend.   I think we can use this syntax,
> without "FOR DATABASE" and "TO USER".
> ----------
> Koichi Suzuki
>
>
>
> 2011/4/1 Michael Paquier <mic...@gm...>:
>> OK I see.
>> So the query will become something like:
>> CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } [ FOR
>> DATABASE dbname ] [TO user_name];
>>
>> Even if Database and user name are not mandatory, at least one of them is
>> necessary to perform a cleanup.
>>
>> Are you OK if I commit the pooler patch first?
>>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>



-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

Okay.   Only a superuser can issue this.   You can commit this patch.

In the future, normal user may want to clean connection assigned to
the current coordinator backend.   I think we can use this syntax,
without "FOR DATABASE" and "TO USER".
----------
Koichi Suzuki



2011/4/1 Michael Paquier <mic...@gm...>:
> OK I see.
> So the query will become something like:
> CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } [ FOR
> DATABASE dbname ] [TO user_name];
>
> Even if Database and user name are not mandatory, at least one of them is
> necessary to perform a cleanup.
>
> Are you OK if I commit the pooler patch first?
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
>

OK I see.
So the query will become something like:
CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } [ FOR
DATABASE dbname ] [TO user_name];

Even if Database and user name are not mandatory, at least one of them is
necessary to perform a cleanup.

Are you OK if I commit the pooler patch first?

-- 
Michael Paquier
http://michael.otacoo.com

I think it is more friendly if we can omit "FOR DATABASE" so that all
the connections assigned to the specified user are cleaned.  Or users
may want to have an option to clean connection connected to the
coordinator backend in use.
----------
Koichi Suzuki



2011/4/1 Michael Paquier <mic...@gm...>:
> No, not yet.
> But I can also write a small extension of CLEAN CONNECTION with:
> CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } FOR DATABASE
> dbname [TO user_name];
>
> The extension being [TO user_name]. If nothing is specified, cleaning is
> made for all the roles on this database.
>
> Is it OK to do such an extension only once the 1st patch is committed?
>
> On Fri, Apr 1, 2011 at 9:46 AM, Koichi Suzuki <koi...@gm...> wrote:
>>
>> I think it's a great step.   Can we clean the connection handling
>> specific user/role, not datanode?
>>
>> ----------
>> Koichi Suzuki
>>
>>
>>
>> 2011/4/1 Michael Paquier <mic...@gm...>:
>> > Hi,
>> >
>> > I took the time to make a couple of tests with the patch attached which
>> > is
>> > the latest version.
>> > As it is not necessary to set password values in connection strings for
>> > users to have an access to the data in the cluster, I removed that in
>> > the
>> > patch attached, making it a little bit simplified.
>> >
>> > Besides, I made a couple of tests with several users in the cluster.
>> > I made it with a cluster having 2 Coordinators, with ports 5432 (Co1)
>> > and
>> > 5452 (Co2).
>> > The 2 users are called ioltas and toto.
>> >
>> > 1) After building the cluster, if the role is not created:
>> > toto@oltania:~$ psql -p 5452 template1
>> > psql: FATAL:  role "toto" does not exist
>> >
>> > 2) ioltas is a superuser, so it creates a new role and a table from
>> > Coordinator 1:
>> > ioltas@oltania:~/pgsql$ psql template1
>> > psql (9.0.3)
>> > Type "help" for help.
>> > template1=# create role toto login;
>> > CREATE ROLE
>> > template1=# create table aa (a int);
>> > CREATE TABLE
>> > template1=# insert into aa values (1),(2);
>> > INSERT 0 2
>> >
>> > 3) then toto can login but cannot access the table:
>> > toto@oltania:~$ psql -p 5452 template1
>> > psql (9.0.3)
>> > Type "help" for help.
>> > template1=> select * from aa;
>> > ERROR:  permission denied for relation aa
>> > template1=> \dp aa
>> >                           Access privileges
>> >  Schema | Name | Type  | Access privileges | Column access privileges
>> > --------+------+-------+-------------------+--------------------------
>> >  public | aa   | table |                   |
>> > (1 row)
>> >
>> > 4) grant access to the table aa for toto from Coordinator 1 (superuser
>> > ioltas)
>> > template1=# grant select on table aa to toto;
>> > GRANT
>> >
>> > 5) Then table access is granted for user toto:
>> > template1=> \dp aa
>> >                             Access privileges
>> >  Schema | Name | Type  |   Access privileges   | Column access
>> > privileges
>> >
>> > --------+------+-------+-----------------------+--------------------------
>> >  public | aa   | table | ioltas=arwdDxt/ioltas+|
>> >         |      |       | toto=r/ioltas         |
>> > (1 row)
>> > template1=> select * from aa;
>> >  a
>> > ---
>> >  1
>> >  2
>> > (2 rows)
>> >
>> > 6) by doing a ps, connections for both users exist
>> > ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
>> > ioltas template1 [local] idle
>> > ioltas template1 ::1(55384) idle
>> > ioltas template1 ::1(48039) idle
>> > ioltas template1 ::1(57169) idle
>> > toto template1 [local] idle
>> > toto template1 ::1(55396) idle
>> > toto template1 ::1(48051) idle
>> >
>> > 7) CLEAN CONNECTION  is also available to close pooler connections:
>> > for user toto:
>> > template1=> clean connection to all for database template1;
>> > ERROR:  must be superuser to clean pool connections
>> > for superuser ioltas:
>> > template1=# clean connection to all for database template1;
>> > CLEAN CONNECTION
>> >
>> > CLEAN CONNECTION cleans up connections for all users on the chosen
>> > database.
>> > So, any comments?
>> > --
>> > Michael Paquier
>> > http://michael.otacoo.com
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Create and publish websites with WebMatrix
>> > Use the most popular FREE web apps or write code yourself;
>> > WebMatrix provides all the features you need to develop and
>> > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>> >
>> > _______________________________________________
>> > Postgres-xc-developers mailing list
>> > Pos...@li...
>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >
>> >
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
>

No, not yet.
But I can also write a small extension of CLEAN CONNECTION with:
CLEAN CONNECTION ON { NODE num,[num] | COORDINATOR num,[num] } FOR DATABASE
dbname [TO user_name];

The extension being [TO user_name]. If nothing is specified, cleaning is
made for all the roles on this database.

Is it OK to do such an extension only once the 1st patch is committed?

On Fri, Apr 1, 2011 at 9:46 AM, Koichi Suzuki <koi...@gm...> wrote:

> I think it's a great step.   Can we clean the connection handling
> specific user/role, not datanode?
>
> ----------
> Koichi Suzuki
>
>
>
> 2011/4/1 Michael Paquier <mic...@gm...>:
> > Hi,
> >
> > I took the time to make a couple of tests with the patch attached which
> is
> > the latest version.
> > As it is not necessary to set password values in connection strings for
> > users to have an access to the data in the cluster, I removed that in the
> > patch attached, making it a little bit simplified.
> >
> > Besides, I made a couple of tests with several users in the cluster.
> > I made it with a cluster having 2 Coordinators, with ports 5432 (Co1) and
> > 5452 (Co2).
> > The 2 users are called ioltas and toto.
> >
> > 1) After building the cluster, if the role is not created:
> > toto@oltania:~$ psql -p 5452 template1
> > psql: FATAL:  role "toto" does not exist
> >
> > 2) ioltas is a superuser, so it creates a new role and a table from
> > Coordinator 1:
> > ioltas@oltania:~/pgsql$ psql template1
> > psql (9.0.3)
> > Type "help" for help.
> > template1=# create role toto login;
> > CREATE ROLE
> > template1=# create table aa (a int);
> > CREATE TABLE
> > template1=# insert into aa values (1),(2);
> > INSERT 0 2
> >
> > 3) then toto can login but cannot access the table:
> > toto@oltania:~$ psql -p 5452 template1
> > psql (9.0.3)
> > Type "help" for help.
> > template1=> select * from aa;
> > ERROR:  permission denied for relation aa
> > template1=> \dp aa
> >                           Access privileges
> >  Schema | Name | Type  | Access privileges | Column access privileges
> > --------+------+-------+-------------------+--------------------------
> >  public | aa   | table |                   |
> > (1 row)
> >
> > 4) grant access to the table aa for toto from Coordinator 1 (superuser
> > ioltas)
> > template1=# grant select on table aa to toto;
> > GRANT
> >
> > 5) Then table access is granted for user toto:
> > template1=> \dp aa
> >                             Access privileges
> >  Schema | Name | Type  |   Access privileges   | Column access privileges
> >
> --------+------+-------+-----------------------+--------------------------
> >  public | aa   | table | ioltas=arwdDxt/ioltas+|
> >         |      |       | toto=r/ioltas         |
> > (1 row)
> > template1=> select * from aa;
> >  a
> > ---
> >  1
> >  2
> > (2 rows)
> >
> > 6) by doing a ps, connections for both users exist
> > ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
> > ioltas template1 [local] idle
> > ioltas template1 ::1(55384) idle
> > ioltas template1 ::1(48039) idle
> > ioltas template1 ::1(57169) idle
> > toto template1 [local] idle
> > toto template1 ::1(55396) idle
> > toto template1 ::1(48051) idle
> >
> > 7) CLEAN CONNECTION  is also available to close pooler connections:
> > for user toto:
> > template1=> clean connection to all for database template1;
> > ERROR:  must be superuser to clean pool connections
> > for superuser ioltas:
> > template1=# clean connection to all for database template1;
> > CLEAN CONNECTION
> >
> > CLEAN CONNECTION cleans up connections for all users on the chosen
> database.
> > So, any comments?
> > --
> > Michael Paquier
> > http://michael.otacoo.com
> >
> >
> >
> ------------------------------------------------------------------------------
> > Create and publish websites with WebMatrix
> > Use the most popular FREE web apps or write code yourself;
> > WebMatrix provides all the features you need to develop and
> > publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> >
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
> >
>



-- 
Michael Paquier
http://michael.otacoo.com

I think it's a great step.   Can we clean the connection handling
specific user/role, not datanode?

----------
Koichi Suzuki



2011/4/1 Michael Paquier <mic...@gm...>:
> Hi,
>
> I took the time to make a couple of tests with the patch attached which is
> the latest version.
> As it is not necessary to set password values in connection strings for
> users to have an access to the data in the cluster, I removed that in the
> patch attached, making it a little bit simplified.
>
> Besides, I made a couple of tests with several users in the cluster.
> I made it with a cluster having 2 Coordinators, with ports 5432 (Co1) and
> 5452 (Co2).
> The 2 users are called ioltas and toto.
>
> 1) After building the cluster, if the role is not created:
> toto@oltania:~$ psql -p 5452 template1
> psql: FATAL:  role "toto" does not exist
>
> 2) ioltas is a superuser, so it creates a new role and a table from
> Coordinator 1:
> ioltas@oltania:~/pgsql$ psql template1
> psql (9.0.3)
> Type "help" for help.
> template1=# create role toto login;
> CREATE ROLE
> template1=# create table aa (a int);
> CREATE TABLE
> template1=# insert into aa values (1),(2);
> INSERT 0 2
>
> 3) then toto can login but cannot access the table:
> toto@oltania:~$ psql -p 5452 template1
> psql (9.0.3)
> Type "help" for help.
> template1=> select * from aa;
> ERROR:  permission denied for relation aa
> template1=> \dp aa
>                           Access privileges
>  Schema | Name | Type  | Access privileges | Column access privileges
> --------+------+-------+-------------------+--------------------------
>  public | aa   | table |                   |
> (1 row)
>
> 4) grant access to the table aa for toto from Coordinator 1 (superuser
> ioltas)
> template1=# grant select on table aa to toto;
> GRANT
>
> 5) Then table access is granted for user toto:
> template1=> \dp aa
>                             Access privileges
>  Schema | Name | Type  |   Access privileges   | Column access privileges
> --------+------+-------+-----------------------+--------------------------
>  public | aa   | table | ioltas=arwdDxt/ioltas+|
>         |      |       | toto=r/ioltas         |
> (1 row)
> template1=> select * from aa;
>  a
> ---
>  1
>  2
> (2 rows)
>
> 6) by doing a ps, connections for both users exist
> ioltas@oltania:~/pgxc$ ps ux | grep template1 | cut -d " " -f 30-
> ioltas template1 [local] idle
> ioltas template1 ::1(55384) idle
> ioltas template1 ::1(48039) idle
> ioltas template1 ::1(57169) idle
> toto template1 [local] idle
> toto template1 ::1(55396) idle
> toto template1 ::1(48051) idle
>
> 7) CLEAN CONNECTION  is also available to close pooler connections:
> for user toto:
> template1=> clean connection to all for database template1;
> ERROR:  must be superuser to clean pool connections
> for superuser ioltas:
> template1=# clean connection to all for database template1;
> CLEAN CONNECTION
>
> CLEAN CONNECTION cleans up connections for all users on the chosen database.
> So, any comments?
> --
> Michael Paquier
> http://michael.otacoo.com
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>