On Fri, Jan 05, 2018 at 01:06:58PM -0500, Doug Ledford wrote: > > Do the userspace daemon's still manage the connection to SRP? > > > > If yes, then the networking information should be relative to the > > namespace of the thing that wrote to the sysfs file.. > > Maybe, maybe not. It depends on the implementation. IIRC you get one > daemon per port, not one daemon per mount. I don't think it depends - if we expose this sysfs file to a container then anything less than using the contain'd net namespace sounds like it is a path to allow the container to escape its net namespace. The complication here is that sysfs creates a device, and that device is currently created in the host namespace. So from a security perspective containers shouldn't even have access to this thing at all without more work to ensure that the created block device is also restriced inside the container. Since it is a sysfs file, and most container systems mount syfs ro, we can probably get away with ignoring namespaces for now? But using the current process namespace is also a good choice. In princinple there can be multiple srp_daemons if they can coordinate which ones do which. For instance a container could run its own srp_daemon restricted to the pkeys the container has access to. If the device stuff above was fixed then this would even make some sense... Otherwise srp_daemon has to run in the host namespace, where the created devices end up and it rightly should not see the netdevices that are assigned to other namespaces. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
