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. My understanding is that 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, amework, etc. This is the same behavior that OS X implements for disk images that your user creates and attaches. Therefore, your user by default has read-write privileges to the device without needing to invoke sudo.
This is in contrast to physical disks which are owned by root:operator. It turns out that in this approach the block special file for the fake disk is owned by your user not by root.
#Maczfs vs zevo how to#
(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.") Having diskarbitrationd automount all datasets allows, among other things, all the datasets to appear in Disk Utility.app and diskutil list. 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. OS X is configured to automount the fake disk. 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. 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. 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.
However, I think we should consider whether we want to adopt ZEVO's approach. If we decide to implement this as a standard feature, we could of course choose any of the three methods above. 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. While this is something a user can do by hand, it seems a bit sketchy for an installer to be editing the sudoers file. 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. %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 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.
0 kommentar(er)
