I have just migrated from a computer double boot (Windows/Ubuntu Hardy) with user data on a FAT32 partition to a new one with a NTFS partition instead. All went OK except that I can read mapsets only when grass (6.3) is started with sudo. If not, I can access locations in the grassdata folder but maptsets are not read. Googling a bit within the list I understand that grass can read only with owner rights (and not only read/write permission) and this explains the difference. I agree with comments that this it looks like a bit over the top regarding security (I may be wrong...).
Of course a solution would be to alvays work as "super user" (sudo) with grass on the NTFS partition, but this is obviously not safe and not in the spirit of Linux... On the other hand, I cannot move the data on the ext3 partition since it was not designated for that (space is limited) and more importantly I suppose this would make problem to read from Windows (e.g. from QGIS under windows - teaching purpose)....
I would really like to use the NTFS partition to get the data shared by the two systems.
I have just migrated from a computer double boot
(Windows/Ubuntu Hardy) with user data on a FAT32 partition
to a new one with a NTFS partition instead. All went OK
except that I can read mapsets only when grass (6.3) is
started with sudo. If not, I can access locations in the
grassdata folder but maptsets are not read. Googling a bit
within the list I understand that grass can read only with
owner rights (and not only read/write permission) and this
explains the difference. I agree with comments that this it
looks like a bit over the top regarding security (I may be
wrong...).
It is not really meant as a "security measure" in the modern sense, more
of ensuring sanity on a multi-user system when working on a collaborative
project. [an original design goal for GRASS; predates the advent of
single user "desktop GIS" (and probably the desktop PC revolution too,
depending on when you put the date for that)].
Of course a solution would be to alvays work as "super
user" (sudo) with grass on the NTFS partition, but this
is obviously not safe and not in the spirit of Linux... On
the other hand, I cannot move the data on the ext3 partition
since it was not designated for that (space is limited) and
more importantly I suppose this would make problem to read
from Windows (e.g. from QGIS under windows - teaching
purpose)....
I would really like to use the NTFS partition to get the
data shared by the two systems.
As anyone an idea about a workaround ?
(re)mount the Windows partition with your user account as the owner.
or force mount as your user ID with the uid= option (see /etc/passwd for
your uid). see fstab and mount man pages. The above restricts mount to
group ID 6 ("disk" group from /etc/group)
the "user" option lets a regular user (non-root) mount it themselves.
I have just migrated from a computer double boot (Windows/Ubuntu Hardy)
with user data on a FAT32 partition to a new one with a NTFS partition
instead. All went OK except that I can read mapsets only when grass
(6.3) is started with sudo. If not, I can access locations in the
grassdata folder but maptsets are not read. Googling a bit within the
list I understand that grass can read only with owner rights (and not
only read/write permission)
To be precise, it requires that you own the current mapset (where new
maps are stored). You can read data from other mapsets provided that
you have the necessary filesystem permissions.
and this explains the difference. I agree
with comments that this it looks like a bit over the top regarding
security (I may be wrong...).
As Hamish says, it's not a security feature; it's to prevent users
from accidentally shooting each other in the foot by trying to share a
mapset directory without fully understanding the implications.
E.g. although you can delete files which you don't own (so long as you
have write permission on the containing directory), you can't delete
directories unless they are empty, and if you don't have write
permission on a directory (and can't chmod it because you aren't the
owner), you can't empty it.
If you allow another user to write to your mapset directory, and they
don't take care to ensure that their umask gives you write permission
(or they use a command which uses e.g. 0755 instead of using 0777 and
leaving the rest to the umask), you may end up with a mapset directory
which is unusable.
As anyone an idea about a workaround ?
Mount the filesystem with ownership set to your user account, as
suggested by Hamish.
Or remove the check from lib/gis/mapset_msc.c and re-compile.
I have just migrated from a computer double boot (Windows/Ubuntu Hardy)
with user data on a FAT32 partition to a new one with a NTFS partition
instead. All went OK except that I can read mapsets only when grass
(6.3) is started with sudo. If not, I can access locations in the
grassdata folder but maptsets are not read. Googling a bit within the
list I understand that grass can read only with owner rights (and not
only read/write permission)
To be precise, it requires that you own the current mapset (where new
maps are stored). You can read data from other mapsets provided that
you have the necessary filesystem permissions.
and this explains the difference. I agree
with comments that this it looks like a bit over the top regarding
security (I may be wrong...).
As Hamish says, it's not a security feature; it's to prevent users
from accidentally shooting each other in the foot by trying to share a
mapset directory without fully understanding the implications.
E.g. although you can delete files which you don't own (so long as you
have write permission on the containing directory), you can't delete
directories unless they are empty, and if you don't have write
permission on a directory (and can't chmod it because you aren't the
owner), you can't empty it.
If you allow another user to write to your mapset directory, and they
don't take care to ensure that their umask gives you write permission
(or they use a command which uses e.g. 0755 instead of using 0777 and
leaving the rest to the umask), you may end up with a mapset directory
which is unusable.
As anyone an idea about a workaround ?
Mount the filesystem with ownership set to your user account, as
suggested by Hamish.
Or remove the check from lib/gis/mapset_msc.c and re-compile.
OK. Thanks to you both Hamish and Glynn. Always better to understand the “why”.