Run zpool, zfs, etc. as non-root user

[ilovezfs]

This is possible on the old MacZFS and ZEVO without setuid.

[larstobi]

+1

[ilovezfs]

This behavior is inherited from upstream OpenZFS, so we may not wish to change it in the default setup. That said, there are a few ways to set this up for yourself already right now.

First way: "setuid"
The most straightforward, but least secure approach, which I specifically was ruling out above, is to specify the set-user-ID-on-execution bit in the mode bits for the executables. For example:

sudo chmod +s /usr/local/sbin/zpool

Second way: "operator group"
a) Do a source install with a simple modification zfs_ioctl.c removing the check for proc_suser, as shown here https://gist.github.com/ilovezfs/7543311

b) Add your user to the "operator" group.

sudo dseditgroup -o edit -a joe -t user operator

c) Make /etc/mtab writable by your user:

sudo touch /etc/mtab && sudo chmod 777 /etc/mtab

d) Change the permissions on the block special files comprised by your vdevs to allow group read-write in addition to owner read-write. The simplest approach to try this method out is to change the permissions manually by running

sudo chmod g+rw /dev/disk#*

on all the relevant block special files.

[By default, OS X will assign ownership of physical disks' block special files to root:operator and permissions 640, granting the root user read-write permissions and the operator group read permissions. OS X's implementation of devfs does not allow you to globally modify the default ownership and permissions on block device special files, so if you want non-default permissions, you have to change these permissions yourself, either manually or programmatically. A launchctl LaunchDaemon could be setup to change the permissions on all partitions with the ZFS GPT partition type, UUID 6A898CC3-1DD2-11B2-99A6-080020736631, during startup. Alternatively, we could register for a notification from the DiskManagement.framework when a new disk appears, and do the permissions change then.]

Third way: "sudoers"
Run sudo visudo to modify the /etc/sudoers file to allow members of the admin group (or create a special zfs group) to run the set of zfs commands with sudo, passwordless.

$ sudo cat /etc/sudoers | tail -1
%admin ALL=(ALL) NOPASSWD: /usr/local/sbin/zdb, /usr/local/sbin/zdb_static, /usr/local/sbin/zfs, /usr/local/sbin/zhack, /usr/local/sbin/zinject, /usr/local/sbin/zpios, /usr/local/sbin/zpool, /usr/local/sbin/zstreamdump, /usr/local/sbin/ztest, /usr/local/sbin/ztest_static

Then alias each command to be the same command invoked by sudo in your bash profile (e.g., alias zpool='sudo zpool'), and make sure the commands and their parent directories are only writable by root. While this is something a user can do by hand, it seems a bit sketchy for an installer to be editing the sudoers file. Perhaps there is a way to factor out this rule into a separate file, and only add a single line to sudoers pointing to the file.

---

If we decide to implement this as a standard feature, we could of course choose any of the three methods above.

However, I think we should consider whether we want to adopt ZEVO's approach. In reality, ZEVO's method likely had a completely different aim, with the possibility of executing zfs commands without root privileges actually an unintended side effect. This is an inference based on a remark, which I believe I recall accurately, by Don in the ZEVO forum (I could try to find it), that the expected usage for ZEVO is that the user invoke most ZEVO commands as root.

ZEVO constructs a "fake disk," as it were, to represent the entire pool, with each child dataset represented as a partition or a partition of a partition of the fake disk. OS X is configured to automount the fake disk. This solves the problem of how to have diskarbitrationd mount every dataset, not just arbitrarily the root dataset, with all other datasets having to be mounted manually. Having diskarbitrationd automount all datasets allows, among other things, all the datasets to appear in Disk Utility.app and diskutil list. (Perhaps someone has another idea for how to get diskarbitrationd itself to mount each dataset, not just how to get it to mount one dataset, and thereby trigger our code to mount all of the child datasets "manually.")

It turns out that in this approach the block special file for the fake disk is owned by your user not by root. This is in contrast to physical disks which are owned by root:operator. Therefore, your user by default has read-write privileges to the device without needing to invoke sudo. This is the same behavior that OS X implements for disk images that your user creates and attaches.

My understanding is that @lundman currently holds the opinion that this approach is something that we might implement at some point in the future, but that he is reluctant to adopt it at all because it may cause the code to diverge significantly from upstream OpenZFS and rely instead heavily on Apple's IOKit, diskarbitrationd, DiskManagement.framework, etc. If this divergence is the likely consequence of this approach, we may find that keeping in sync with upstream is more difficult and that maintaining the code is less straightforward. In addition, it would require a significant investment of time in learning more about IOKit, etc., with perhaps primarily cosmetic benefits, such as the better GUI representation in Disk Utility.app.

[ilovezfs]

It looks like one possible way to do this is

http://atnan.com/blog/2012/02/29/modern-privileged-helper-tools-using-smjobbless-plus-xpc

[ilovezfs]

As a start, 72d8832

[ilovezfs]

openzfsonosx/spl@6130aa3