Does setuid=on work on ZFS datasets, or is the man page for zfs misleading?
stilezy at gmail.com
Wed Apr 11 11:36:38 UTC 2018
(Sorry, slight reword, my mistake, underlined correction:
" So instead of forcing all files to be owned by (say) userX, and giving
userX some rights, I could acept that the owner is arbitrary, give the
owner no rights at all, *create a group called "data_file_owner", add my
desired file+dir owner to the data_file_owner group, and give the
data_file_owner group the access rights* over the dataset root dir that I
would have given the owner. My understanding is that even on ZFS that setup
*can* be configured to forcibly inherit when files+dirs are created." )
On 11 April 2018 at 12:32, Stilez Stilezy <stilezy at gmail.com> wrote:
> On 10 April 2018 at 06:45, Andriy Gapon <avg at freebsd.org> wrote:
>> On 06/04/2018 20:42, Stilez wrote:
>> > So the question stands - is there any working method to ensure files in
>> a ZFS
>> > dataset or contained dir have a predetermined owner? Including within
>> ACLs if I
>> > missed the right page?
>> My assumption was that the ownership change was not an end goal and there
>> was a
>> wider context related to access management.
>> In other words, why do you want to change file ownership unless you want
>> change the file's access rights... In my opinion, Unix file ownership is
>> a part
>> of Unix file access model.
> Good question. Four reasons come to mind:
> 1. I'm a comparative newcomer to FreeBSD security and related matters, and
> don't have the skill/knowledge to make assumptions that an experienced
> fbsd-er might make. My assumption is that whatever owner permissions/ACLs
> are set at, and whatever exec rights exist, files are more vulnerable to
> issues I leave open or mistakes I make, if they accidentally have a
> privileged owner, compared to a non privileged one. A lot of work I do in
> CLI is done with su-ing to a privileged account. The files don't need a
> privileged owner, so why give them one, or expose them to having one?
> 2. Another reason is that some branches of the file system are accessed
> via Samba, and if ACLs aren't correct, Windows tends to look at the owner
> as the account able to fix it. If files accumulate different owners, that
> could become a real pain to sort out as the file system is in the millions
> of files. This probably isn't so important because Samba allows owner
> inheritance on any dir, but I'd like to rely on OS controls rather than
> Samba controls.
> 3. An old principle of computing - if something isn't needed but adds
> complication, don't do it. I don't need the files to have varied owners, so
> varied owners becomes at best useless, at worst a pain at some
> unforeseeable future time.
> 4. Finally of course, ACLs and ownership committed within short and long
> term snapshots never can be changed or fixed. If any of these ever do give
> rise to a problem, I won't be able to fix it short of an insane amount of
> cloning/sending/rebuilding of the pool and every snapshot in it.
> At present I'm currently tightening my "archived files" pool's
> permissions, having dealt with most other basics. I'm starting from the top
> down - get ownership right, then groups, then ACLs/permissions on
> If FreeBSD can't do ownership inheritance, I have to think whether it's
> actually a problem and if so what to do. Perhaps the simplest option is to
> treat ownership as untrusted and give null ACLs (no rights at all) to the
> owner; instead just condition all access rights on user/group only. As far
> as I understand, that should be as secure/effective, and will inherit.
> So instead of forcing all files to be owned by (say) userX, and giving
> userX some rights, I could acept that the owner is arbitrary, give the
> owner no rights at all, create a user or group called "data_file_owner",
> and give that user/group the access rights over the dataset root dir that I
> would have given the owner. My understanding is that even on ZFS that setup
> *can* be configured to forcibly inherit when files+dirs are created.
> Would that angle work as I intend? Any issues/warnings for me, that I
> should be aware of?
More information about the freebsd-fs