[GRASS-user] Fwd: GRASS on SSHFS
Daniel Lee
lee at isi-solutions.org
Wed Dec 12 01:19:37 PST 2012
>
> Have you tried using the uid= and/or idmap=user mount options?
>
> http://manpages.ubuntu.com/manpages/precise/man8/mount.fuse.8.html
>
> idmap=user comes from sshfs (which doesn't appear to have any official
> documentation), and is supposed to map UIDs.
>
That sounds promising. I think I'll skip that though, since now we've got
GRASS running on the server and the server's a lot more comfortable for me
anyway due to the long calculations ;)
> Historically, there are two reasons:
>
> 1. To prevent multiple GRASS sessions from using the same mapset
> directory. A lock file prevented a user from having more than one
> session, and the ownership check prevented anyone other than the
> directory's owner from using a directory as the current mapset.
>
> 2. Because otherwise people try to share mapsets by making them
> group-writable, then discover that they can't replace maps due to
> permission issues.
>
> Specifically, if you allow someone else to write to your mapset
> directory, and that user has a umask of 022 (or more), any directories
> which they create (e.g. cell_misc/<mapname> directories) will be mode
> 755 (drwxr-xr-x) or less, meaning that you can't remove any files from
> that directory, and thus won't be able to delete that directory. This
> will prevent you from removing or overwriting the map using GRASS
> commands.
>
> Point #1 is no longer relevant, but point #2 is, at least on
> multi-user systems.
>
> On Windows, the checks are bypassed because Windows' stat() function
> doesn't report the owner and Windows doesn't have getuid().
>
> None of this would be a problem except for the fact that it's now
> common to use non-Unix filesystems on Unix (where "non-Unix
> filesystem" includes any filesystem where "touch file ; ls -l file"
> reports an owner that doesn't match the output of "whoami").
>
Thanks for the explanation! That's good to know :)
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20121212/cb1ceaad/attachment.html>
More information about the grass-user
mailing list