[GRASS-user] Fwd: GRASS on SSHFS

Glynn Clements glynn at gclements.plus.com
Tue Dec 11 04:41:06 PST 2012


Daniel Lee wrote:

> Here's the output of ls -la:
> 
> ls -la
> total 12
> drwxrwxrwx 1 1002 9150  22 Dec  7 12:15 .
> drwxrwxrwx 1 1002 9150  23 Dec  7 11:09 ..
> drwxrwxrwx 1 1002 9150 129 Dec  7 12:14 PERMANENT
> 
> I think Glynn's right about the permissions being the problem. Even though
> everybody has permissions here, the folders' owner is my SSH user, which is
> different than the username on my own machine. It seems that's the source
> of my troubles. Sadly, I don't see a way of getting around that except for
> doing some really complicated SSH tunneling stuff or recompiling GRASS. The
> easier way out is just contacting the system administrator of the server
> I'm working on, which I've done - hopefully she'll have installed GRASS on
> it by tomorrow, so that's one less thing to worry about.

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 aside, though, is there a specific reason that GRASS requires the user
> to own a mapset, rather than just have write permission?

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").

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-user mailing list