1

I have an unusual requirement where I need to mount the same filesystem on a client multiple times, but each mount offering a different view of the underlying data, based on the group permissions of the underlying directories and files.

I have achieved this in the past with NFS and the all_squash and anongid /etc/exports option, making a specific mount appear as though the user had a specific group ID. It effectively filtered access to the underlying filesystem by forcing the accessing user's group.

Unfortunately I can't use that in this scenario, as the filesystem will be Amazon EFS (effectively an NFS server, but without any configuration options).

I have looked at bindfs, and this provides a force-group option, but this is the reverse of what I want, since it forces all files to have a specific group, rather than forcing the client to have a specific group, looking at the files unchanged.

I did see a mention of something called filterfs, but it appears to be long dead.

Does anybody know a way to get a filtered view of a file system for a single user by effectively changing the user's group on an ad-hoc basis (without using sudo, since the user is a webserver daemon).

5
  • 1
    Hmm, are you sure your needs can't be met by mapping the group, like bindfs --map=@files-group:@webserver-daemon-group ?
    – sourcejedi
    Aug 22, 2018 at 21:15
  • @sourcejedi that sounds interesting, though I haven't made the mental leap yet between all_squash and mapping groups. Would you be able to explain with an example in an answer?
    – Phil
    Aug 28, 2018 at 8:14
  • 1
    The above would effectively allow group webserver-daemon-group to access files as if they were a member of the group files-group. This seems similar, but not identical, to all_squash with anongid=files-group. I don't know if that meets your needs and I don't have a list handy of the cases where behaviour would be different. The files-group could be varied for different mounts for a similar effect to varying anongid. (And if you want you could vary webserver-daemon-group to restrict access, without needing to vary access permissions on a parent directory.)
    – sourcejedi
    Aug 28, 2018 at 8:57
  • I think this could work. If you'd like to add an answer to this effect I'll accept it. Or I'll go ahead and add an answer with my eventual findings once I've tried it all out.
    – Phil
    Aug 28, 2018 at 14:28
  • 1
    Hi. I don't plan to write this as an answer, I'd be worried I was being hypothetical & handwavy. If it works for you, I think an answer that shows it would be perfectly valid. I have no problem if you want to write it up.
    – sourcejedi
    Aug 28, 2018 at 16:06

1 Answer 1

1

Thanks to @sourcejedi for pointing me in the right direction.

In the original NFS setup, all_squash was used to make a daemon user appear to have a specific group (set by anongid). For this example, assume the group ID is 601. This view onto the original filesystem could therefore enforce permissions on files / directories based on the mounted filesystem's anongid being 601. Permissions appear like they evaluated at the level of the NFS mount, independent of the daemon user's actual group permissions. Another NFS mount onto the same filesystem with different all_squash settings effectively shows a different view of the files, as if the user had different group membership.

Using bindfs --map the same result can be achieved with a little different setup. A sample configuration binds a filesystem such that any files / directories with group ID 601 in the underlying filesystem appear to have group ID 599 in the mounted filesystem:

bindfs --map=@601/@599 --create-for-group=601 --create-for-user=600 --create-with-perms='u=rwD:g=rwD:o=' $FS_ROOT $MOUNT_ROOT/view601

Now, when listing files in $MOUNT_ROOT/view601 the daemon user sees any file that has group 601 instead having group 599. By giving the daemon membership of group gid 599, the permissions are effectively enforced again based on the mount. If a different mount mapped gid 602 to 599, the files in the same underlying filesystem would be available to the same user if they originally had group 602 (rather than 601) now mapped to 599, making them available to daemon.

2
  • 1
    You can (and should) accept your own answer here :-)
    – cooperised
    Sep 5, 2020 at 16:25
  • @cooperised thanks for the prompt
    – Phil
    Sep 9, 2020 at 11:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .