On Tue, Sep 26 2017, Stefan Hajnoczi wrote: > On Mon, Sep 25, 2017 at 11:40:26PM -0400, J. Bruce Fields wrote: >> On Tue, Sep 26, 2017 at 12:08:07PM +1000, NeilBrown wrote: >> > On Fri, Sep 22 2017, Daniel P. Berrange wrote: >> > Rather than a flag, it might work to use network namespaces. >> > Very early in the init sequence the filesystem gets mounted using the >> > IPv6 link-local address on a client->host interface, and then a new >> > network namespace is created which does not include that interface, and >> > which everything else including firewall code runs in. Maybe. >> >> That seems closer, since it allows you to hide the interface from most >> of the guest while letting some special software--qemu guest agent?-- >> still work with it. That agent would also need to be the one to do the >> mount, and would need to be able to make that mount usable to the rest >> of the guest. >> >> Sounds doable to me? >> >> There's still the problem of the paranoid security bureaucracy. >> >> It should be pretty easy to demonstrate that the host only allows >> point-to-point traffic on these interfaces. I'd hope that that, plus >> the appeal of the feature, would be enough to win out in the end. This >> is not a class of problem that I have experience dealing with, though! > > Programs wishing to use host<->guest networking might still need the > main network namespace for UNIX domain sockets and other > communication. Did I miss something.... the whole premise of this work seems to be that programs (nfs in particular) cannot rely on host<->guest networking because some rogue firewall might interfere with it, but now you say that some programs might rely on it.... However I think you missed the important point - maybe I didn't explain it clearly. My idea is that the "root" network namespace is only available in early boot. An NFS mount happens then (and possibly a daemon hangs around in this network namespace to refresh the NFS mount). A new network namespace is created and *everthing*else* runs in that subordinate namespace. If you want host<->guest networking in this subordinate namespace you are quite welcome to configure that - maybe a vethX interface which bridges out to the host interface. But the important point is that any iptables rules configured in the subordinate namespace will not affect the primary namespace and so will not hurt the NFS mount. They will be entirely local. There should be no need to move between namespaces once they have been set up. NeilBrown > > For example, the QEMU guest agent has a command to report the IP > addresses of the guest. It must access the main network namespace to > collect this information while using a host<->guest socket to > communicate with the hypervisor. > > I think this can be achieved as follows: > 1. open /proc/self/ns/net (stash the file descriptor) > 2. open /var/run/netns/hvnet & call setns(2) to switch namespaces > 3. socket(AF_INET6, SOCK_STREAM, 0) to create host<->guest socket > 4. call setns(2) to switch back to main namespace > > In other words, the program stays mostly in the main network namespace > and only enters the host<->guest namespace to create sockets. > > setns(2) with a network namespace requires CAP_SYS_ADMIN so it's not > very practical. > > Is there an alternative that makes using the host<->guest network > namespace less clunky? > > Stefan > -- > 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
Attachment:
signature.asc
Description: PGP signature
