[Pkg-zfsonlinux-devel] WIP branch for ZFS 0.7.0

Fabian Grünbichler f.gruenbichler at proxmox.com
Fri Aug 11 09:13:47 UTC 2017


On Fri, Aug 11, 2017 at 07:46:15AM +0200, Petter Reinholdtsen wrote:
> 
> No one replied so far, so I guess I could chip in a bit. :)
> 

Thanks!

> [Fabian Grünbichler]
> > - incorporate man page fixes I submitted upstream to get rid of some
> >   lintian warnings
> 
> Perhaps best to wait for upstream to include these, to not divert
> further from upstream than necessary?  What are the upstream issue URLs?

sorry for not making this clear - I did not incorporate them yet because
they are just for cleanliness' sake, and I wanted to wait for upstream
to at least merge them into master before adding the patches to
packaging.

already merged:
SPL: [1,2,3]
ZFS: [4]

still up for discussion is one related to dracut in ZFS[5], but as I a
have no experience with dracut I am not sure whether I am the right
person to follow through with that one ;)

> 
> > 1.) /bin vs /sbin
> >
> > how should we handle /dev/zfs and the read-only zfs/zpool commands being
> > user accessible upstream since 0.7? moving the zfs and zpool binaries to
> > /bin and putting a compat symlink in /sbin should work AFAICT
> 
> I'd say the binaries have not changed in nature, and still belong in
> sbin/ even if they now also work without root privileges.
> <URL: https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SBINSYSTEMBINARIES >
> state that sbin/ should contain "utilities used for system
> administration (and other root-only commands) are stored in /sbin,
> /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for
> booting, restoring, recovering, and/or repairing the system in addition
> to the binaries in /bin.", which still seem correct for the zfs/zpool
> commands.

I am not sure as it seems to fall into a grey area of sorts. e.g. there
is already stuff like 'ip' and 'udevadm' which IMHO are in a similar
category, and both ship symlinks in /sbin and the actual binaries in
/bin.

the new 'zpool status/iostat -c SOMETHING' option is not allowed to be
used as root unless overruled via an environment variable (for IMHO
valid security reasons).

I think this has some potential for confusion of the following sort:

user at sid-zfs:~$ sudo zpool status -c
[sudo] password for user:
Available 'zpool status -c' commands:
  fault_led       Show value of the disk enclosure slot fault LED.
  upath           Show the underlying path for a device.
[...]
  pwr_cyc         Show SMART power cycle count (ATA).
  media           Show whether a vdev is a file, hdd, or ssd.
user at sid-zfs:~$ sudo zpool status -c serial
Can't run -c with root privileges unless ZPOOL_SCRIPTS_AS_ROOT is set.
user at sid-zfs:~$ zpool status -c serial
-bash: zpool: command not found

more experienced users will probably know about sbin and $PATH or maybe
how to find where a binary is located:

user at sid-zfs:~$ whereis zpool
zpool: /sbin/zpool /usr/share/man/man8/zpool.8.gz
user at sid-zfs:~$ /sbin/zpool status -c serial
  pool: rpool
 state: ONLINE
  scan: none requested
config:

        NAME                                            STATE     READ WRITE CKSUM  serial
        rpool                                           ONLINE       0     0     0
          raidz1-0                                      ONLINE       0     0     0
            scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part1  ONLINE       0     0     0       -
            scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part1  ONLINE       0     0     0       -
            scsi-0QEMU_QEMU_HARDDISK_drive-scsi2-part1  ONLINE       0     0     0       -
            scsi-0QEMU_QEMU_HARDDISK_drive-scsi3-part1  ONLINE       0     0     0       -

errors: No known data errors

but we'd probably teach some other users to set the environment variable
and expose themselves to unnecessary risk in the course.

all that said I have no very strong feelings on this, so keeping them in
sbin is fine as well. dropping the old (deprecated upstream) sudoers
file probably warrants a NEWS entry anyway, and that could be used to
point people to the new way of accessing some ZFS stuff with
unprivileged users.

> 
> I have no idea about the test stuff.

neither do I - it just got a lot more than in 0.6.5, so carrying it in
zfsutils-linux got 'wronger' IMHO.


1: https://github.com/zfsonlinux/spl/pull/642
2: https://github.com/zfsonlinux/spl/pull/643
3: https://github.com/zfsonlinux/spl/pull/644
4: https://github.com/zfsonlinux/zfs/pull/6492
5: https://github.com/zfsonlinux/zfs/pull/6491




More information about the Pkg-zfsonlinux-devel mailing list