System: sys-fs/zfs-0.6.2-r5 sys-kernel/hardened-sources-3.13.6-r3 We create a lot of zfs snapshots. if we try to enter a zfs snapshot directory we get: bash: cd: $snapshotdir: Too many levels of symbolic links I think upstream has a bug for that but it is tagged as resolved: https://github.com/zfsonlinux/zfs/issues/816 Is this bug back again?
Found a problem with grsecurity. Syslog is constantly spammed with: kernel: grsec: denied exec of usermode helper binary /bin/sh located outside of /sbin and system library paths how can i solve this? disable grsec completely?
Created attachment 379606 [details, diff] Patch to workaround kernel upcall limitations in GrSec 3.0 I usually take care of non-packaging ZFS-related bugs at the upstream tracker as it gets more eye balls on problems. An unfortunate consequence of that is that this slipped through the deluge of bug mail that I receive. I am usually available and responsive on IRC, which tends to make matters worse as users cut into the front of the line by pinging me there. That being said, I have attached a patch that must be applied to both sys-fs/zfs-kmod and sys-fs/zfs. It should resolve this and I regret that I did not get it into Gentoo's ebuilds sooner. It will be going into the next ebuild revisions as soon as it passes upstream review.
Thanks for adding the attachment. I will try to test the patches over the weekend if i find the time.
I just encountered this problem as well on a new ZFS file server I'm setting up. The patch worked for me. Thanks.
Richard, Has there been any movement or updates on this? I just saw that updated ebuilds hit the tree with a number of post-0.6.3 patches included, but snapshots are still unusable with grsec enabled. The patch you previously applied does still work, but it has a side-effect: once I cd into a snapshot directory and read/copy a file, it somehow triggers an error that gets reported in syslog every 5 minutes: Dec 17 12:57:27 host kernel: [ 8206.363530] grsec: denied exec of usermode helper binary /bin/sh located outside of /sbin and system library paths Dec 17 13:02:28 host kernel: [ 8506.807965] grsec: denied exec of usermode helper binary /bin/sh located outside of /sbin and system library paths Dec 17 13:07:28 host kernel: [ 8807.252151] grsec: denied exec of usermode helper binary /bin/sh located outside of /sbin and system library paths <SNIP> I have not been able to track down exactly what's causing that error, or why it's occurring every 5 minutes, but it'll persist until I reboot the server. If I cd into a snapshot directory and read a file again (I'm not sure if it's the cd or read operation that triggers it), it'll start doing it again until the next reboot. This behavior occurred prior to this latest update as well. I was hoping a proper fix would be included this time. :-) If you do have any update on this, would you mind sharing? Until then, I'll continue using the patch as it's far better than having no usable snapshot functionality at all. Thanks.
I decided to begin enforcing Linux mainline stable policies on patches that I apply to the ZoL ebuilds, so this had been excluded from it. I have been busy enough chasing down some other issues that I have not yet upstreamed this. As for the periodic message, the issue is that ZoL will attempt to automatically unmount the .zfs directory after a timeout and it does this using /bin/sh. Unfortunately, umount is in /bin, rather than /sbin, so modifying the module to stop using /bin/sh in favor of /bin/umount will not solve the problem. I have a WIP patch that I wrote to try to avoid the need for going into userland when the umount is done by trying to use `kern_unmount()`, but I had trouble getting it right back in May and put this down until now. I am right now working on an overhaul of memory management and /dev/zfs ioctl stabilization. I can context switch back to this after I finish those. I am pushing myself to try to get them done before the New Year, but they are substantial enough changes that I cannot guarantee when I finish them.
This should have been fixed in 0.6.3. We are now on 0.6.5.3-r3, so I am closing this as resolved.
