On Fri, Sep 22, 2017 at 03:14:57PM -0400, J. Bruce Fields wrote: > On Fri, Sep 22, 2017 at 12:55:24PM +0100, Daniel P. Berrange wrote: > > On Fri, Sep 22, 2017 at 07:43:39AM -0400, Chuck Lever wrote: > > > If firewall configuration is a chronic problem, let's address that. > > > > This just isn't practical in the general case. Even on a single Linux OS > > distro there are multiple ways to manage firewalls (Fedora as a static > > init script, or firewalld, and many users invent their own personal way > > of doing it). There are countless other OS, many closed source with 3rd > > party firewall products in use. And then there are the firewall policies > > defined by organization's IT departments that mandate particular ways of > > doing things with layers of approval to go through to get changes made. > > > > IOW, while improving firewall configuraiton is a worthy goal, it isn't > > a substitute for host<->guest file system sharing over a non-network > > based transport. > > I guess what's confusing to me is you're already depending on a ton of > assumptions about the guest: > > - it has to be running a recent kernel with NFS/VSOCK support. > - it has to have all the nfs-utils userspace stuff, a > /usr/bin/mount that works the way you expect, and an > /etc/nfsmount.conf that doesn't have any odd options. > - it has to have a suitable mount point somewhere that the admin > knows about. > - probably lots of other stuff > > It's odd that the firewall configuration is the one step too far. The key factor is considering which pieces are liable to significant or complex interactions with other usage of the OS, and are thus liable to be accidentally misconfigured or at risk of breaking during usage. The configuration of network interfaces and firewalls is very major risk area compared to the other pre-requisites. Providing a kernel/userspace with the feature is taken care of by the distro vendor and OS admins can't break this unless they go out of their way to prevent loading of the kernel modules which is not a likely scenario. Making a mount point is straightforward and not something that other services in the system are liable to break. Potentially the mount point creation can be either baked into the guest OS pre-built disk image, or populated by metadata from another source. The nfsmount.conf options are a possible source of concern, but IIUC, anything set there is possible to override via explicit args to mount. The way in which network interfaces are configured though is a major source of complexity & unknowns because it is not something the distro vendor just defines once. There are countless different tools to configure network interfaces on Linux alone, and many permutations of how the actual interfaces / routing are setup. Firewall setup is a similar place of complexity & unknowns, because not only are there many different tools to manage it, but you get well into the realm of policy defined by the organizations deploying it. Expecting things to "just work" in this area is just unrealistic. It is a big part of why virtualization platforms all provide dedicated paravirtualized devices for communication between host and guest, that is independant of networking. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
