Project

General

Profile

Actions

Idea #7831

open

[FUSE] Add --umask, --fmask, --dmask options to control file permissions

Added by Brett Smith over 8 years ago. Updated 27 days ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
FUSE
Target version:
Story points:
1.0
Release:
Release relationship:
Auto

Description

Background

arv-mount uses mode 0777 for files and directories.
  • This is (probably) more permissive than desired when combined with --allow-other: other users can write.
  • This is misleading when not combined with --allow-other: it looks like other users can read and write, but they can't.
  • All files are executable, which is not always desired.

Other FUSE drivers like sshfs and ntfs-3g establish the convention of using "umask" to specify permissions (e.g., "-o umask=022", not "-o mode=0755"). Unlike "mode", the term "umask" is suggestive of the fact that it can subtract from the maximum sensible permissions, but can't add fake permissions (e.g., "--mode 0777" could be misunderstood to mean "advertise writable files, even on a readonly mount").

Fix

arv-mount should accept the following options, where N is an octal number.

  • --fmask=N -- remove these bits from the mode of files.
  • --dmask=N -- remove these bits from the mode of directories.
  • --umask=N -- remove these bits from the mode of files and directories (set both fmask and dmask to N).

The default is N=022 if --allow-other-user is given, otherwise N=077.

Files will have mode (0777 - fmask). Directories will have mode (0777 - dmask).

Except: read-only objects never have "write" bits on, regardless of umask.

Examples:

Arguments Directories Files
none drwx------ -rwx------
--fmask=0177 drwx------ -rw-------
--allow-other drwxr-xr-x -rwxr-xr-x
--allow-other --dmask=027 --fmask=0137 drwxr-x--- -rw-r-----
Actions #1

Updated by Brett Smith over 8 years ago

  • Target version set to Arvados Future Sprints
Actions #2

Updated by Brett Smith over 8 years ago

We want a switch for this, either --mode and/or --permissions, with default 0755.

Actions #3

Updated by Tom Clegg over 8 years ago

  • Description updated (diff)
  • Story points set to 0.5
Actions #4

Updated by Brett Smith over 8 years ago

  • Description updated (diff)
  • Story points changed from 0.5 to 0.0
Actions #5

Updated by Brett Smith over 8 years ago

  • Story points changed from 0.0 to 1.0
Actions #6

Updated by Brett Smith over 8 years ago

  • Tracker changed from Bug to Idea
  • Subject changed from [FUSE] Default permissions on writable files should be 0755 or 0775, not 0777 to [FUSE] Add a --mode switch to set file permissions
Actions #7

Updated by Brett Smith over 8 years ago

  • Description updated (diff)
Actions #8

Updated by Peter Grandi over 8 years ago

I have discussed this a bit on the #Arvados IRC channel. Our issue is related and it is that we have collections that are "unrestricted", and some that are restricted. For each different "restricted" collection using our current NFS archive we have used a different UNIX group and 'u=rwX,g=rX,o=' permissions, and put authorized users in that group. Having a FUSE mount per-user is usually good enough, but we would prefer for automated processes to have per-group mounts too, and something like --mode seems useful.

Except that the FUSE library already supports the standard options default_permissions, umask, uid and gid, which would be really nice to have, and it is difficult for me to see why having a new option name mode would be necessary.

In an ideal world arv-mount would be as compatible as possible with sshfs which is rather widely used, or would be a module for avfsd (especially if you have IP ownership concerns about reusing sshfs code). Both support all the FUSE options including umask, uid, gid.

Actions #9

Updated by Peter Grandi over 8 years ago

BTW currently we are looking into a workaround that might be useful to other users and is moderately common in UNIX practice, for the purpose of restricting access:

  • Create a UNIX user and group with a name like "restricted", and a corresponding Arvados group and user.
  • Assign the restricted data to that Arvados group and user.
  • Create a directory like /mnt/restricted/ owned by restricted:restricted with permissions ug=rx,o=, so not travcersable by "other" users.
  • Create a directory with a name like /mnt/restricted/keep/ and arv-mount --user-allow-other ... /mnt/restricted/keep.
  • Make the UNIX users of people allowed to access the restricted data members of group restricted.

To spell out the obvious, even if the permissions on /mnt/restricted/keep/ and subdirectories/files are wide-open by default, the permissions on /mnt/restricted/ palliate that.

It would still be better to be able to mount with umask, uid, gid set appropriately like AVFS and SSHFS (and most other FUSE filesystems) allow; or even finer one like NTFS-3g's splitting of umask into fmask and dmask.

Actions #10

Updated by Peter Grandi over 8 years ago

BTW since this is a bit of a pet peeve of ours, a further note: the default permissions right now should be:

With --allow-other-user:
  • With --read-only: 00550 for directories, 00440 for files.
  • With --read-write: 00750 for directories, 00640 for files.
Without --allow-other-user:
  • With --read-only: 00500 for directories, 00400 for files.
  • With --read-write: 00700 for directories, 00600 for files.

And'ed of course with the access the mounting Arvados token has to the collection...

Actions #11

Updated by Tom Clegg over 8 years ago

  • Subject changed from [FUSE] Add a --mode switch to set file permissions to [FUSE] Add --umask, --fmask, --dmask options to control file permissions
  • Description updated (diff)

I don't think supporting the "-o umask=N" command line syntax needs to be included here. It does seem nice to follow the same convention as mount.* (and sshfs etc). OTOH it surely wouldn't enable anyone to use arv-mount as a drop-in replacement for anything, and AFAIK there is no llfuse feature for parsing command line options so "--umask=N" is going to be more expedient than "-o umask=N" for getting the umask feature merged.

Defaulting to --fmask=0177 (and --dmask=027 --fmask=0137 when --allow-other) seems more natural to me. However, defaulting to --fmask=077 is backward compatible so I'm inclined to do that instead.

Actions #12

Updated by Ward Vandewege over 2 years ago

  • Target version deleted (Arvados Future Sprints)
Actions #13

Updated by Peter Amstutz about 1 year ago

  • Release set to 60
Actions #14

Updated by Peter Amstutz 27 days ago

  • Target version set to Future
Actions

Also available in: Atom PDF