[GRASS5] Re: v.database
blazek at itc.it
Thu Nov 25 11:46:15 EST 2004
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
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.
> 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?
>> 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
>> I think that there is problem to connect a vector with a table in a
>> 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
>> The contemporary access can be avoid by a lock.
>> - -- 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
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.4 (GNU/Linux)
>> -----END PGP SIGNATURE-----
More information about the grass-dev