[GRASSLIST:5002] Re: v.database

[Radim Blazek]

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