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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
