[...]
>>> For the general nosuid, nodev flags, I think we can do something like we
>>> have for the <features/> element in the domain XML.
>>>
>>
>> So that means to me that every option currently possible in mount would
>> need to be listed. Doesn't that feel excessive? Not that mount changes
>> that often, but I would think it's awfully painful to take that route.
>> Especially for some of the "more complicated" mount options.
>
> The mount command options are a tiny, trivial set compared to QEMU
> command line options. The goal here is not to have simple libvirt
> code, rather is to have portable & simple application code. Libvirt
> exists to provide an abstraction layer over OS specific commands
> line "mount" which can have different syntax on each OS. eg FreeBSD
> mount command options may differ from Linux mount command options.
And this last line is the biggest concern over providing or "by default"
adding "-o nosuid,nodev,noexec" for NFS mount command line.
Secondary to that is the "what if" by doing so we break some existing
configuration for some reason that was making use of a pool volume in
some really strange manner that we didn't expect just because one of
those mount options wasn't set by default. Not that it seems the 3
mentioned ones would cause such pain, but the precedence of adding
options by default in general.
>
> I'm not suggesting implementing support for every single mount
> option though. Only those that we actually have a compelling
> reason to support, just as we've not implemented every single
> QEMU arg.
>
Understood. Of course as soon a couple are implemented, someone else's
favorite is desired, etc. It's the picking and choosing which are
compelling enough to support vs. just allowing or even providing a
supportable mechanism to allow arbitrary command options vs.
implementing "some" and leaving the rest to be added via namespace.
Right now the "some" are:
nfsvers='n' [add only if new XML exists]
nosuid
nodev
noexec
and maybe additionally 'ro' if [new] <readonly/> was set.
Just trying to get all the "parameters" set before starting a v3...
John
[...]
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
