You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using zxfer and at the receive and having a user that does not have access to /sbin does not work.
This is because the script specifically looks for the zfs binary in /sbin/zfs instead of relying on it being in the users $PATH at two places in the script (works for me after I changed it).
The use case I have for not wanting the user to have access to /sbin is a locked down user for only receiving where I have constructed a directory with symlinks for allowed binaries to run. This directory is then added to the restricted user $PATH.
Is there a good reason for wanting it to be /sbin/zfs? (on a side note love BSDNow, keep up the good work!)
The text was updated successfully, but these errors were encountered:
Looking at it, it seems the reason is that those are meant to be the paths on the remote system, so 'which zfs' from your local system, might not be the right path. I suppose you could try to depend on ZFS being in the $PATH on the remote site.
I am not sure if changing this is a good idea or not.
Using zxfer and at the receive and having a user that does not have access to /sbin does not work.
This is because the script specifically looks for the zfs binary in /sbin/zfs instead of relying on it being in the users $PATH at two places in the script (works for me after I changed it).
The use case I have for not wanting the user to have access to /sbin is a locked down user for only receiving where I have constructed a directory with symlinks for allowed binaries to run. This directory is then added to the restricted user $PATH.
Is there a good reason for wanting it to be /sbin/zfs? (on a side note love BSDNow, keep up the good work!)
The text was updated successfully, but these errors were encountered: