[...]
>> 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
[...]