Need help understanding permissions for mount points in jails

[Monkey_Demon]

I have several directories in a pool called Volume1, and I want to access 3 of them in a jail. In the FreeNAS shell they are:

• /mnt/Volume1/Documents (webdav, webdav),
• /mnt/Volume1/Media (media, media),
• and /mnt/Volume1/Users (root, users).

The terms in parentheses are respectively the directory's owner and group. Their child directories and files all belong to their parent's group (e.g, everything below Documents belongs to webdav group), and their owners are either the users who created them or the owner of the parent directory (e.g., the owner of everything below Media is either media or the individual user who owns the file or folder.)

A jail, rclone, has a directory at /mnt/Backup that belongs to root and has group wheel. Each of the three directories above is mounted as a mount point under Backup. E.g., the source at /mnt/Volume1/Documents is mounted at the destination /mnt/Volume1/iocage/jails/rclone/root/mnt/Backup/Documents.

Now here's where I get lost. If the rclone jail's root issues ls -l -R /mnt/Backup within the rclone jail, one gets a listing including all the directories in the directory tree but no files. However, if one does this from the system shell, using ls -l -R /mnt/Volume1 or, e.g., ls -l -R /mnt.Volume1/Documentsinstead, one gets a much longer output showing files as well as directories. I believe the problem is related to permissions and to user and group memberships, but I don't know how to fix this.

Section 15.3.3 of The Fine Manual (11.3-RELEASE) discusses the workflow for using mount points in jails. Item 1 in the workflow description begins:

1. Determine the name of the user and group account used by the application. For example, the installation of the transmission application automatically creates a user account named transmission and a group account also named transmission. When in doubt, check the files /etc/passwd ....

Well, in this case the jail will primarily be used by rclone but not exclusively. So the implicit assumption of one 1 application per jail does not hold. Besides, rclone does not appear in either the jail or system's /etc/passwd file, so there's no guidance as to what name or group to use. The assumption that each application defines a user & group also does not hold.

Now I suppose I could create a dummy user and group, "rclone," and add this user to the webdav, media, and users groups. And then have this rclone user run everything in the jail. (I'm not completely sure how. Put su rclone in the .login file?) But is this really the best way?

Continuing with the manual's instructions, Item #4 says:

If the jail accesses existing data, edit the permissions of the pool or dataset so the user and group accounts have the desired read and write access. If multiple applications or jails are to have access to the same data, create a new group and add each needed user account to that group.​

Let's deconstruct this a bit:

• "Edit the permissions of the pool or dataset" -- since these exist outside the jail, I presume this means we're to do so from the FreeNAS GUI.
• But reading on, "so the user and group accounts have the desired read and write access." What accounts are these? And if they're the users and groups of the children of, say, the Documents dataset, these children already have the desired permissions based on existing usernames and groups.
• "If multiple applications or jails are to have access to the same data, create a new group and add each needed user account to that group." In this case, yes multiple applications or jails are to have access (e.g., both rclone and plex need to access the files under Media). Then "add each needed user account to that group." Huh? What are the needed user accounts? Plex and rclone? And what if one of these needs rw permission, while the other must be confined to only r permission? And what if different users of the FreeNAS system have access to one of these jails (e.g., all users on the system can access the plex jail.) Are they the "needed users" to whom TFM alludes?

Continuing, Item #5 says, "If an area of storage is being set aside for that jail or individual application, create a dataset. Edit the permissions of that dataset so the user and group account has the desired read and write access." Is the dataset devoted to housing the jail itself, or is it a dataset belonging to the jail?

And exactly what is the "user and group account" to which this refers? Is it the nonexistant user and group account that rclone was assumed to create and join but did not? Is it one of the users or groups defined in the system's /etc/passwd and /etc/groups files?

Please help me make sense of this. Or at least tell me how to make this work as intended.

 

[Basil Hendroff]

You will find this thread useful for your understanding of what's going on. Essentially, you need to create a user outside the jail with the same UID/GID as the user inside the jail.

rclone isn't listed in the spoiler. I'm assuming there's a user rclone in the jail. To find its UID/GID, issue the command id rclone.

 

[garm]

Understanding jail permissions is fine I guess, but why not use rclone from the FreeNAS UI?

the short version of permissions is;

users do thing, groups grant access.
users and groups have a unique id (this is important)
To grant a user in a jail access to a directory in FreeNAS the user need to a member of the owning group in the jail.
So, an example;
You have some directory in FreeNAS, /mnt/foo owned by the group bar with the gid 10234. You use nullfs and mount that directory in the jail at /mnt/foo and want user to have access. Create a group in the jail called bar with the gid 10234 and make user a member. Then make sure the mounted directory in the jail have the same permissions with chown.

 

[Basil Hendroff]

but why not use rclone from the FreeNAS UI?

Good point.

 

[Monkey_Demon]

Good point.

... why not use rclone from the FreeNAS UI?

Thanks for your help. Regarding your question, I've addressed it on another thread.

 

[garm]

Thanks for your help. Regarding your question, I've addressed it on another thread.

Well I’m not buying that argument.. but for the sake of this thread.. permissions are easy, just make the rclone user member of every owner group in the jail

 

[Monkey_Demon]

Well I’m not buying that argument.. but for the sake of this thread.. permissions are easy, just make the rclone user member of every owner group in the jail

Thanks. I'm still a bit confused about this.

Let's say our system has 3 users: Foo, Bar, and Baz. Their home directories are all in /mnt/Volume1/Users. Initially each home directory belongs to the respective user, and all three belong to the "users" group. Now suppose Foo and Baz decide to work on a project together, and to collaborate they start creating and sharing files belonging to a different group: project1. So now the rclone user would have to belong to both users and project1.

But in a large organization, of say several thousand users, there could be hundreds of groups organized around different projects. (Or even a smaller organization, like an academic department: it could have 15-20 faculty members, dozens of grad students, hundreds undergraduate majors, and perhaps 5-10 support staff members. Additionally, such an organization is likely to divide responsibilities among system administrators, with one being in charge of administering new user accounts and groups, and another being in charge of maintaining backups. So every time a new project starts up, the two administrators would have to coordinate. All this seems extremely cumbersome.

Furthermore, suppose (1) that some persons on a project need write permissions to certain files, while others need to be restricted to read only, and (2) for whatever reason the cloud storage can (2.a) be augmented from sources other than rclone and (2.b) needs to sync with the FreeNAS system, so that a file deleted from the cloud also is deleted from the NAS. If a file is read-only for its group, then only its owner can delete it. Therefore, the rclone users will not be able to delete it should it be deleted from the cloud.

In short, the practice of creating a pseudo user, rclone, and assigning it to all possible groups seems like a cumbersome kludge that can't possibly work in all foreseeable cases.

I hope I'm wrong. Perhaps I misunderstand the solution. Or perhaps there's a more simple, elegant solution. Do I correctly understand the solution of creating a rclone user who belongs to all potential groups? Would such a solution have the limitations I describe? Is there a more simple solution?

 

[garm]

For large complex systems you need ACLs and AD for sane management.. UNIX permissions are a bit more hands on

being a backup solution i assume rclone runs as root, but a jail root do not have root access in FreeNAS for obvious reasons, so if you want to run rclone in a jail you need to make the user running rclone (all services are run by a user, otherwise they would have no access..) a member of all the target owning groups, hens my statements

Understanding jail permissions is fine I guess, but why not use rclone from the FreeNAS UI?

Well I’m not buying that argument..