[GRASSLIST:4965] Re: v.database

[Radim Blazek]

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 at 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-----