[OpenIndiana-discuss] ZVOL (et al) /device node access rights

[Andrej Javoršek]

Hello,
I'm running VB guests as normal (unprivileged) user and I have impression
that ownership (I'm using chown on zvol's) is not always lost during reboot.
The other part of my comment was joke on my behalf, since restarts of host
OS are rare and often I forget to check if guests came up properly.
But I completely agree with you that the behaviour is not favorable.

Regards Andrej

On Mon, Oct 15, 2012 at 4:39 PM, Jim Klimov <jimklimov at cos.ru> wrote:

> I am not sure I understood your comment?..
>
>
> 2012-10-15 11:14, Andrej Javoršek wrote:
>
>> Hello,
>> I have impression that it is not always necessary to chown raw zvol's.
>>
>
> It seems necessary when we need to allow a non-root user to use the
> zvol directly, such as a backing store for his VM's virtual disk.
>
>
>  It happens occasionally on some zvols (and only when I initiate reboot
>> and forget about it)  :)
>>
>
> What happens? The need to chown?
>
> Sorry for misunderstandings if any,
> //Jim
>
>
>
>
>> Regards Andrej
>>
>> On Sun, Oct 14, 2012 at 3:08 PM, Jim Klimov <jim at cos.ru> wrote:
>>
>>  While updating the Wiki page on virtualization, Edward Ned Harvey
>>> wrote of, and brought to my attention, this peculiar situation:
>>>
>>> A VirtualBox VM can use delegated zvols as "dsk" or "rdsk" devices
>>> on the host, just like it can use delegated raw disks or partitions,
>>> likely iSCSI volumes and other block devices. According to Edward,
>>> block devices yield better performance than VDI files for VM disks.
>>> A VM can be executed by an unprivileged user, and thus the device
>>> node needs to be RW accessible to that non-root user (whom and why
>>> to trust - that's the admin's problem, OS should not limit that).
>>>
>>> So, the problem detected with ZVOLs (and I expect it can have a
>>> wider range on other devices) is that the ownership of the device
>>> node for a zvol is forgotten upon reboot or other pool reimport.
>>> That is, the node used by a VM should be chown'ed upon every VM
>>> startup. That's inconvenient, so to say.
>>>
>>> I played more with this and found that I can also set ACLs with
>>> /bin/chmod on device nodes, and that is even remembered across
>>> reboots, however with /dev/zvol/*dsk/pool/vol being a dynamically
>>> assigned symlink like /devices/pseudo/zfs at 0:4(,raw) there is a
>>> problem: the symlink and device node is created when I look at
>>> it (i.e. upon first "ls" or another access to the /dev/zvol/...
>>> object), and the device node occupies the first available number.
>>> The /devices filesystem seems to remember ACL entries (but not
>>> ownerships) across reboots only in conjunction with its object
>>> names, so upon each reboot (reimport) of the pool, the same
>>> device node name can get assigned to different zvols.
>>>
>>> This is not only "useless" in terms of stably providing access
>>> to certain devices for certain users, but also harmful as after
>>> a reboot an unexpected user (among those earlier trusted) can
>>> gain access to incorrect devices (and might even enforce that
>>> somehow, by being first to access the device at the correct
>>> moment) and cause DoS or intentional illicit access to other
>>> users' data.
>>>
>>> So here is the picture "as is". I am not sure what exactly to ask,
>>> so I guess it's a call for opinions on how the situation can be
>>> improved, in terms of remembering correct ownerships and ACLs for
>>> those devices (not nodes) that the rights were set for, in order
>>> to both increase usability and security of non-root device access.
>>>
>>> In the particular case of ZVOL devices, I guess attributes can
>>> be added to the ZVOLs that would hold the POSIX and ACL access
>>> rights and owner:group info (do people agree that is a worthy RFE?).
>>>
>>> For non-zfs devices like local disk or iscsi or USB - I am not sure
>>> if the problem exists the same way (not tested) or how it can be
>>> addressed if it exists (some config file for devfs?)
>>>
>>> Thanks,
>>> //Jim Klimov
>>>
>>
>