Markus Neteler wrote: > The point here is (as experienced on our local shared network > grassdata/ recently): > - GRASS allows users to enter their own mapset(s) > - GRASS allows users to read all mapsets and write into the current (own) one > - GRASS does not allow to modify the mapset of a different user
In 7.0, the last one can be suppressed by setting the environment variable GRASS_SKIP_MAPSET_OWNER_CHECK to any non-empty string. Of course, you still need write permission on the underlying files and directories. > So far so nice. > > Assume that several users belong to the same group. If now the group > write flag is enabled for mapsets, users can delete them even if they > are not their own. This is fine since someone (admin) must have > allowed for this. > > Now back to GRASS: A user runs a session in his/her mapset with > group-write enabled. This is against the GRASS internal policy where > others cannot write into your own mapsets with GRASS commands. > > Wish for improvement: > When starting a session in a mapset with group/other-write enabled, > issue a warning to inform the user about this in the startup script. > This would follow the "least-surprise" paradigm. > Feasible? Yes. Just don't do anything too invasive. Bear in mind that paying too much attention to filesystem permissions has a similar problem to the ownership check, namely that most Unix systems are capable of accessing non-Unix filesystems (e.g. FAT, NTFS, CIFS). This is one reason why I added the ability to suppress the check. -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev