Sorry, but it does not work as I expected. I have got access to
Postres with schemas and I discoverd that it is impossible to
GRANT SELECT ON SCHEMA. To give access to a table in schema
you must user must:
GRANT USAGE ON SCHEMA myschema to user1;
GRANT SELECT ON myschema.mytable to user1;
=> vector and database modules or database drivers must
GRANT SELECT ON created tables automaticaly to some group.
And I have no idea how. We can use db_create_table() in vector modules
(should be used anyway) but what to do with tables created by
db.execute?
Radim
Radim Blazek wrote:
I have removed v.database. Vector modules will use
default values set by db.connect.
db.tables returns schema.table if chemas are available.
You can use v.db.connect table=schema.table
Default schema can be set by db.connect.
WARNING: default schema is used by all db.* modules.
All this works with Postgres only.
Radim
Leonardo Lami wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is maybe too confusing to have separate default driver/database for
db.* and v.* modules. First I thought, that in some cases
it could be useful, but usually both groups of modules use the same
database. Driver/database options can be used if necessary (v.in.db).
What do you think, should we remove v.database and use db.connect
settings also for vectors?
Radim
-------------------------------------------------------
I think there is no problem if you remove v.database.
I do not remember if you resolved the problem about v.db.connect and schema.
I think that there is problem to connect a vector with a table in a schema
with v.db.connect.
db.login was added to 5.7. It can be used to set user and password
for driver/database.
WARNING: password is stored as text in $HOME/.grasslogin5
User and password from database definition (db.connect,v.db.connect) is
no more used.
This change was necessary to allow work in groups. Now it is possible
to give only select privileges to group or others. Typicaly
location -> database
mapset -> schema
UNIX user -> database user
UNIX group -> database group
Then user can grant select on schema to group and public.
Administrators should keep in sync database and UNIX users,
especially don't forget to remove database user if UNIX user
is removed.
If you revoke access to group or others using g.access,
you should also revoke privileges on related database schema.
I'am agree.
I'd like to know if is it possible to allow that more users work on the same
mapset?
The contemporary access can be avoid by a lock.
Thanks
- -- Leonardo Lami
lami@faunalia.it www.faunalia.it
Via Colombo 3 - 51010 Massa e Cozzile (PT), Italy Tel: (+39)349-1310164
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBpHVq92hCyP73w7ARAtd4AKCAsI0KIqPJdyMTycHcPmclfcCYdQCeOjd1
cXeNkqpeYizclo5hRyrc7lo=
=lz+S
-----END PGP SIGNATURE-----
The problem was resolved for Postgres. All vector modules grant by default select on created table to public. If you want to grant select also to group, set the group name using db.connect group=.
Here is an example how to setup Postgres with GRASS for work in groups:
Administrator:
createuser -p -h srv1 user1 # set password on prompt to pwd1
createuser -p -h srv1 user2 # set password on prompt to pwd2
echo "create group group1 with user user1,user2" | psql -h srv1
createdb -h srv1 db1
echo "grant create on database db1 to group group1" | psql -h srv1
User1:
echo "create schema schema1" | psql -h srv1 db1
echo "grant usage on schema schema1 to group group1, public" \
| psql -h srv1 db1
db.connect driver=pg database='host=srv1,dbname=db1' \
schema=schema1 group=group1
db.login driver=pg database='host=srv1,dbname=db1' \
user=user1 password=pwd1
User2:
echo "create schema schema2" | psql -h srv1 db1
echo "grant usage on schema schema2 to group group1, public" \
| psql -h srv1 db1
db.connect driver=pg database='host=srv1,dbname=db1' \
schema=schema2 group=group1
db.login driver=pg database='host=srv1,dbname=db1' \
user=user2 password=pwd2
User1 can read vector attributes created by user2 and vice versa.
Please test this if you are working in group with GRASS!
Radim
Radim Blazek wrote:
Sorry, but it does not work as I expected. I have got access to
Postres with schemas and I discoverd that it is impossible to
GRANT SELECT ON SCHEMA. To give access to a table in schema
you must user must:
GRANT USAGE ON SCHEMA myschema to user1;
GRANT SELECT ON myschema.mytable to user1;
=> vector and database modules or database drivers must
GRANT SELECT ON created tables automaticaly to some group.
And I have no idea how. We can use db_create_table() in vector modules
(should be used anyway) but what to do with tables created by
db.execute?
Radim
> Radim Blazek wrote:
I have removed v.database. Vector modules will use
default values set by db.connect.
db.tables returns schema.table if chemas are available.
You can use v.db.connect table=schema.table
Default schema can be set by db.connect.
WARNING: default schema is used by all db.* modules.
All this works with Postgres only.
Radim
Leonardo Lami wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is maybe too confusing to have separate default driver/database for
db.* and v.* modules. First I thought, that in some cases
it could be useful, but usually both groups of modules use the same
database. Driver/database options can be used if necessary (v.in.db).
What do you think, should we remove v.database and use db.connect
settings also for vectors?
Radim
-------------------------------------------------------
I think there is no problem if you remove v.database.
I do not remember if you resolved the problem about v.db.connect and schema.
I think that there is problem to connect a vector with a table in a schema
with v.db.connect.
db.login was added to 5.7. It can be used to set user and password
for driver/database.
WARNING: password is stored as text in $HOME/.grasslogin5
User and password from database definition (db.connect,v.db.connect) is
no more used.
This change was necessary to allow work in groups. Now it is possible
to give only select privileges to group or others. Typicaly
location -> database
mapset -> schema
UNIX user -> database user
UNIX group -> database group
Then user can grant select on schema to group and public.
Administrators should keep in sync database and UNIX users,
especially don't forget to remove database user if UNIX user
is removed.
If you revoke access to group or others using g.access,
you should also revoke privileges on related database schema.
I'am agree.
I'd like to know if is it possible to allow that more users work on the same
mapset?
The contemporary access can be avoid by a lock.
Thanks