Bug 28294
| Summary: | dump of vinum based file systems by device name fails | ||
|---|---|---|---|
| Product: | Base System | Reporter: | ahd <ahd> |
| Component: | bin | Assignee: | Joerg Wunsch <joerg> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.3-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
The problem is in vinum itself -- it builds the volume device nodes wrong, with an owner group of wheel instead of operator. This prevents non-root members of operator from accessing the drives. Compare these device nodes for regular disk slices: crw-r----- 2 root operator 13, 0x0003000a Jun 16 23:47 /dev/da1s2 crw-r----- 2 root operator 13, 0x00030008 Jun 16 23:47 /dev/da1s2a crw-r----- 2 root operator 13, 0x00030009 Jun 16 23:47 /dev/da1s2b crw-r----- 2 root operator 13, 0x0003000a Jun 16 23:47 /dev/da1s2c crw-r----- 2 root operator 13, 0x0003000b Jun 16 23:47 /dev/da1s2d crw-r----- 2 root operator 13, 0x0003000c Jun 16 23:47 /dev/da1s2e crw-r----- 2 root operator 13, 0x0003000d Jun 16 23:47 /dev/da1s2f crw-r----- 2 root operator 13, 0x0003000e Jun 16 23:47 /dev/da1s2g crw-r----- 2 root operator 13, 0x0003000f Jun 16 23:47 /dev/da1s2h to the vinum subdirectory: crw------- 1 root wheel 91, 0x40000001 Jun 18 13:44 Control crw------- 1 root wheel 91, 0x40000002 Jun 18 13:44 control crw------- 1 root wheel 91, 0x40000000 Jun 18 13:44 controld drwxr-xr-x 2 root wheel 512 Jun 18 13:44 drive crw-r----- 1 root wheel 91, 2 Jun 18 13:44 export drwxr-xr-x 2 root wheel 512 Jun 18 13:44 plex crw-r----- 1 root wheel 91, 3 Jun 18 13:44 scratch drwxr-xr-x 2 root wheel 512 Jun 18 13:44 sd crw-r----- 1 root wheel 91, 1 Jun 18 13:44 usr crw-r----- 1 root wheel 91, 0 Jun 18 13:44 var drwxr-xr-x 6 root wheel 512 Jun 18 13:44 vol The scratch, usr, export, and var devices should all be owned by group operator. Note that because vinum attempts remake to the device nodes in /dev/vinum at every reboot, it's unclear if a simple chmod command would solve the issue for existing vinum volumes across reboots. -ahd- Responsible Changed From-To: freebsd-bugs->grog Over to vinum maintainer. Responsible Changed From-To: grog-> joerg joerg has offered to fix this problem. State Changed From-To: open->closed Fixed in both, the kernel part (for DEVFS under -current), and the vinum(8) utility (for non-DEVFS cases, due for MFC into 4.x). |
I'm not sure this is a bug in vinum (kern), dump (bin), or amanda (ports). minerva has a number of vinum mirrored volumes (see above) and amanda24-client-2.4.2p1_2. Attempts to dump the vinum resident file systems via amanda fail because amanda attempts to invoke dump with the device name, not the mount point, and dump fails. amanda debug log sample: sendsize: debug 1 pid 2242 ruid 2 euid 2 start time Wed Jun 20 10:49:31 2001 /usr/local/libexec/amanda/sendsize: version 2.4.2p1 calculating for amname '/usr', dirname '/usr' sendsize: getting size via dump for /usr level 0 sendsize: running "/sbin/dump 0hsf 0 1048576 - /dev/vinum/usr" running /usr/local/libexec/amanda/killpgrp DUMP: Date of this level 0 dump: Wed Jun 20 10:49:31 2001 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/vinum/usr (/usr) to standard output DUMP: Cannot open /dev/vinum/usr ..... (no size line match in above dump output) ..... asking killpgrp to terminate Fix: Workaround is specify use of GNU TAR for the dump program. How-To-Repeat: Request amanda dump (via dump) a vinum based file system.