<br><br><div class="gmail_quote">On Thu, Oct 23, 2008 at 1:14 AM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
Matt B wrote:<br>
<br>
> > Note that GRASS won't let you select a mapset as the current mapset<br>
> > (where new files are stored) unless you own it. Write permission isn't<br>
> > sufficient.<br>
> ><br>
> > If you are creating a location which is to be shared by multiple<br>
> > users, you either need to create a mapset directory for each user,<br>
> > owned by the user, or grant all such users write permission on the<br>
> > location directory so that they can create their own mapset directory<br>
> > (which they will own).<br>
><br>
</div><div class="Ih2E3d">> Thanks for the heads up on this Glynn, my problem is that I'm on a dual boot<br>
> system and I'm storing mapsets/data on an NTFS drive. It's being<br>
> automatically mounted with the owner set as root and read/write permission<br>
> for everyone. If I put the data on the ext3 filesystem, it works. I'll mess<br>
> around with fstab and mount the data drive as the appropriate user. Having<br>
> said that.... it does seem to me that this sort of check is doubling up.<br>
> File permissions are usually run by the file system/OS. While having a<br>
> sanity check for "read/write" access is a good idea, checking for ownership<br>
> seems a little over the top. <insert newby user disclaimer here>.<br>
<br>
</div>AFAICT, the check exists because otherwise people grant group-write<br>
permission to mapset directories without fully understanding the<br>
consequences. In particular, you can end up being unable to modify,<br>
rename or remove files because they reside in a directory created by<br>
another user and lacking group-write permission.<br>
<br>
The possibility of "free-for-all" filesystems (i.e. where not only are<br>
all files and directories world-writable, but where any new files and<br>
directories will always be world-writable) has only arisen recently.<br>
<br>
The native Windows builds skip the ownership check, but Unix builds<br>
will perform it regardless of the filesystem type. Unfortunately, I<br>
don't know of any (robust and portable) way to detect when a Windows<br>
filesystem is being used on Unix.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div>Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>></div></div></blockquote><div><br>After banging my head against the ntfs wall for a little while here (for some reason the guys who write the ntfs stuff also have some ideas on who should be allowed to mount / own filesystems and block devices).<br>
While writing software for the lowest common denominator isn't necessarily a bad thing, including this sort of thing in the software to stop people overwriting others files does seem a little redundant and in my case annoying. I'll add another disclaimer in case someone points out that theres an easy fix for this as I'm the guy who can't get an ntfs partition mounted without it being owned by root (without recompiling stuff that would probably break on the next apt-get update).<br>
<br>I'll be running this from my somewhat smaller ext3 partition for the time being unless someone can point me at a "don't do this check" button (please, someone point me at that button).<br><br>Matt<br>
</div></div><br>