[GRASS-dev] GRASS resets group access rights

GRASS GRASS developer
1

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. Example

Original data with access rights set so that group members can edit the data:

$ ls -lr dbf/pokrycie_przyborow_u65_10k.dbf vector/pokrycie_przyborow_u65_10k
-rw-rw---- 1 user1 users-grass 466 2008-07-02 19:07 dbf/pokrycie_przyborow_u65_10k.dbf

vector/pokrycie_przyborow_u65_10k:
razem 140
-rw-rw---- 1 user1 users-grass 1986 2008-07-02 19:07 topo
-rw-rw---- 1 user1 users-grass 3195 2008-07-02 19:07 hist
-rw-rw---- 1 user1 users-grass 176 2008-07-02 19:07 head
-rw-rw---- 1 user1 users-grass 75 2008-07-02 19:07 dbln
-rw-rw---- 1 user1 users-grass 116326 2008-07-02 19:07 coor
-rw-rw---- 1 user1 users-grass 369 2008-07-02 19:07 cidx

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

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

$ umask
0022

$ ls -l file
-rw-rw---- 1 user1 users-grass 0 lip 11 14:16 file
$ mcedit file
$ ls -l file
-rw-rw---- 1 user1 users-grass 11 lip 11 14:18 file

$ su user2
$ mcedit file (edit the file an save)
$ ls -l file
-rw-rw---- 1 user1 users-grass 11 lip 11 14:19 file

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?

Maciek

--
Maciej Sieczka
www.sieczka.org

2

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@gclements.plus.com>

3

Glynn Clements pisze:

Maciej Sieczka wrote:

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,

As well as the dbf file it seems - right?

while the others are edited in-place.

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.

For now I put 'umask 7' into my grass64 executable, which forces access
rights I desire for files newly created by GRASS.

Maciek

--
Maciej Sieczka
www.sieczka.org

4

Maciej Sieczka pisze:

Glynn Clements pisze:

Maciej Sieczka wrote:

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.

For now I put 'umask 7' into my grass64 executable, which forces access
rights I desire for files newly created by GRASS.

And, forgot to say, I apply a following patch to allow non-owners to access mapsets, per your instructions some months ago:

--- mapset_msc.c 2008-04-05 11:47:54.000000000 +0200
+++ mapset_msc.c.patched 2008-04-05 11:56:40.000000000 +0200
@@ -108,9 +108,9 @@

  #ifndef __MINGW32__
      if (info.st_uid != getuid())
- return 0;
+ return 1;
      if (info.st_uid != geteuid())
- return 0;
+ return 1;
  #endif

      return 1;
@@ -141,9 +141,9 @@

  #ifndef __MINGW32__
      if (info.st_uid != getuid())
- return 0;
+ return 1;
      if (info.st_uid != geteuid())
- return 0;
+ return 1;
  #endif

      return 1;

Maciek

--
Maciej Sieczka
www.sieczka.org

5

Maciej Sieczka wrote:

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

> For now I put 'umask 7' into my grass64 executable, which forces access
> rights I desire for files newly created by GRASS.

And, forgot to say, I apply a following patch to allow non-owners to
access mapsets, per your instructions some months ago:

Ah; that would probably explain why this hasn't been noticed before.

This may even be the reason for the mapset ownership restriction. I
had always assumed that it was related to locking, but it may actually
be due to problems caused by ownership and permissions when creating
files.

I suspect that the same issue will also apply to cell/fcell files.
Those are rename()d over any existing file when the map is closed.

But, hang on a minute; why does this cause problems? If the files are
being replaced atomically (rather than modified in-place), it
shouldn't matter whether anyone has write permission. To delete or
replace files, you only need write permission on the directory, not
the file.

AFAICT, it should only be an issue if the files are sometimes modified
in-place and sometimes replaced atomically.

That still leaves the issue of a user creating a directory without
group write permission. If the directory isn't empty, other users
won't be able to delete or replace any files within it, and thus won't
be able to delete the directory itself (although it can be moved or
renamed, so long as you have write permission on the parent
directory).

Ultimately, this is an inherent problem with shared directories. They
require a certain amount of trust, not just that users aren't
malicious, but also that they're careful.

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