Sean,
I’ll try to address your concerns. Sorry this became so long, but your profile says you’re a basic user. I’m a relative newbee to FreeNAS too, but I’ve been using and administering computers since the 1960s. I think this gives me some helpful perspective, and from you comments I surmise that a view from 20,000 feet would be helpful. So here goes.
History: Invention of the Wheel
When I first used Unix in the late 1970s, files and directories had 3 kinds of permissions: owner, group, and other. Although I had administered IBM mainframes, back then I was only a Unix end-user, and AFAIK, files could be associated with only one group. Then, somewhere along the line, Access Control Lists (ACL) were introduced, at least in FreeBSD, which allow much more fine-grained access control. In particular, multiple groups can be associated with a single file or directory, which in Free/TrueNAS carries over to datasets.
Unix itself had evolved from other operating systems (the name itself was a reaction to “Multics” – an experimental project at MIT). Early Unix systems often ran on Digital Equipment Corporation’s PDP computers, which commonly shipped with the TOPS operating system. As a security measure, TOPS distinguished between super- and and ordinary users. Instead of everyone with the superuser (or root) password having access to superuser status, such potentially dangerous privileges were reserved for the “big wheels” in the organization. Hence, the “Wheel group.”
Who Needs Wheels?
The question is, do you really want your datasets to belong to the wheel group, especially in the jail? Your datasets are “Install,” “Music,” and “Data.” Now I don’t know how you use them or intend to use them. But I’m working with five datasets, which are somewhat similar: Documents, FTP, Media, TimeMachine_dataset, and Users. By my conscious decisions, none of them has wheel as a group owner. Documents is in the webdav group, FTP is in shared_ftp, Media is in media, TimeMachine_dataset is in TimeMachine, and Users is in users.
By making such distinctions, I can better control access to the datasets. For example, I’m the only member of the webdav group because I use WebDAV to maintain a large library of pdf files, but if a file allows “other” users to read it, anyone with WebDAV access to the dataset can read it (but not change or delete it). So you may want to reconsider if you really want your three datasets to be in the wheel group at the FreeNAS level.
But even if you do, this doesn’t mean they have to be in the wheel group within the jail. See this thread and the ACL documentation for FreeBSD. The question you need to ask is if Duplicati needs superuser (“big wheel”) privileges in the jail, or if simple read/write/execute access to the datasets you’re backing up would be sufficient. I suspect the latter is the case. And if so, you can use groups other than wheel within the jail and still leave wheel as a group owner outside of it.
Baby You Can’t Drive My Car
I think you’re on the right track at the end of your post. But instead of a generic group, backup_gid, I would suggest two things.
First, a minor point: all groups have GID’s, so adding “_gid” to a group name is redundant. But then again, every dataset you access from the Duplicati jail is likely to be there because you’re backing it up. So if this is the only place you care about the backup group, using “backup” as a name would also be redundant.
This brings up the second, more useful point. There’s a ton of information about not only Free/TrueNAS, but also general *nix system administration. (One free [2011] handbook for *nix system administration is 1344 pages long!) But the basic idea of groups is to allow users to collaborate or who have similar needs to share data, while excluding those who don’t have such needs.
So, go back to your original three datasets and consider them in this light. Even if you’re currently the only user on your system, imagine that someday you’ll have many users using it. (Maybe because you use it for a business that grows, your family grows and someday includes hacker children, you make new friends and share music with them, etc.) Now consider your datasets and decide if they need identical access permissions or are logically different from each other. (Remember that as the system administrator you can give yourself sufficient access that such differences become almost invisible to you.) Then decide what groups you need, what datasets should be associated with which groups, and which users should be in which group.
You may decide, as I did, that each dataset is (potentially) associated with unique needs. For example, you may want to allow some friends to listen to your music but not to access your data. If you associate Music and Data with different group owners, making such distinctions become trivial. OTOH, if you associate them both with a single “backup” group because they share the characteristic that they’re backed up (as most of your files should be), then you may have overlooked other important distinctions between the two datasets and their potential users.
In Short
This all boils down to three simple principles:
- Think through your ultimate and potential use of datasets, and create groups and assign group ownership accordingly.
- When customizing access from a jail, as much as possible try to confine the customizations only to the jail.
- Because security is always a concern, don’t overdo usage of “owner” or “other” permissions – the former may give away too much power, while the latter may give power to the wrong users; instead, use groups judiciously to group subsets of users with similar needs and to exclude users without such needs.