protecting zfs snapshot info

Borja Marcos borjam at sarenet.es
Wed Aug 16 10:19:38 UTC 2017


> On 15 Aug 2017, at 14:20, Mike Tancsa <mike at sentex.net> wrote:
> 
> On 8/14/2017 8:57 AM, Mike Tancsa wrote:
>> On 8/14/2017 2:47 AM, Borja Marcos wrote:
>>> 
>>>> On 12 Aug 2017, at 19:14, Mike Tancsa <mike at sentex.net> wrote:
>>>> 
>>>> 
>>>> Is there a way in zfs to protect non root users from seeing snapshots ?
> 
>>> Good question and it’s a problem indeed. The .zfs directory is always created
>>> and it can be hidden but it’s still accessible. It’s a security problem that prevents
>>> an effective access revocation for a directory/file, I guess that’s what you mean.
>> 
>> Yes, something like an extra option
>> hidden | visible | unmounted
> 
> I did come across this thread
> 
> https://github.com/zfsonlinux/zfs/issues/3963
> 
> but it seems Linux specific or at least I dont see how its done on FreeBSD.

Yes, it seems to be Linux specific and as far as I know there’s no way to do it on FreeBSD right now.

I would vouch for a third state added to the “snapdir” variable, but I wouldn’t call it “disabled”. “unmounted” or
maybe “noauto” is much better in my opinion. The .zfs directory should still be created (maybe hidden when
in “noauto” state in order to prevent it from being created by a user.

I don’t think a new permission is needed to control that variable, though. The “snapshot” permission
implies that “mount” should be allowed as well at least in the current versions. So it’s redundant. Or,
actually, the “noauto” value for “snapdir” would eliminate the requirement for “mount” permissions. 

I mean: Right now the “snapshot” permission requires “mount” because the snapshot is mounted upon creation
like it or not. If the snapshot was not automatically mounted thanks to the “noauto” value for “snapdir” it would be
possible to have a user authorized to manage snapshots but unable to mount them.

Given the very sensible nature of “mount” in Unix it makes sense. 







Borja.




More information about the freebsd-fs mailing list