[GRASS-dev] GRASS resets group access rights

Glynn Clements glynn at gclements.plus.com
Sun Jul 20 12:36:17 EDT 2008


Maciej Sieczka wrote:

> When editing vector maps, GRASS changes permissions of 3 existing files
> - topo, cidx and the dbf file, from "-rw-rw----" to "-rw-r--r--", which 
> means that the group members cannot edit the map anymore.

Historically, GRASS has only allowed you modify maps which are in the
current mapset, and has only allowed you to use a mapset which you own
as the current mapset.

In that sense, modifying maps which you don't own shouldn't even be
possible.

> Example

> Now edit the data as user2 and see the group write rights are removed:
> 
> $ ls -lr vector/pokrycie_przyborow_u65_10k 
> dbf/pokrycie_przyborow_u65_10k.dbf
> -rw-r--r-- 1 user2 users-grass  375 2008-07-02 19:14 
> dbf/pokrycie_przyborow_u65_10k.dbf
> 
> vector/pokrycie_przyborow_u65_10k:
> razem 140
> -rw-r--r-- 1 user2 users-grass   1949 2008-07-02 19:14 topo
> -rw-rw---- 1 user1 users-grass   3402 2008-07-02 19:13 hist
> -rw-rw---- 1 user1 users-grass    176 2008-07-02 19:14 head
> -rw-rw---- 1 user1 users-grass     75 2008-07-02 19:14 dbln
> -rw-rw---- 1 user1 users-grass 116326 2008-07-02 19:14 coor
> -rw-r--r-- 1 user2 users-grass    349 2008-07-02 19:14 cidx

Right; the top and cidx files are replaced with new files, while the
others are edited in-place.

> Other programs don't seem to be doing this, no matter what the intial
> umask is. I have tried with a simple text file:

Programs which modify files in-place (e.g. fopen(..., "w") etc) will
normally leave the ownership and permissions intact (i.e. they won't
change unless the program explicitly chooses to change them).

Programs which modify files by writing out a new version then
rename()ing it over the original will only retain ownership and
permissions either by explicit action or by coincidence. By default,
the file will be owned by its creator and have the permissions set
according to the umask.

In some cases, there are good reasons to prefer one approach over the
other, as it affects the behaviour of concurrent access and of hard
links (and, on some file systems, file attributes and/or metadata). 
But usually, the behaviour is accidental; a consequence of however the
programmer implemented it, probably without much consideration.

> As you can see although 2 different users (members of the same group)
> edit the file, permissions were not changed. Yet in GRASS they are. Is 
> this OK?

Not really. How to handle this situation will need to be resolved if
and when we actually decide to remove the restriction that GRASS
doesn't allow you to modify other users' files. Until then, the goal
should be to determine why that restriction isn't being honoured, and
how to fix it.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list