On Mon, 16 Sep 2019 09:56:29 +0000, Petr Machata wrote: > Inside the namespace you can do "ip netns id" to get the namespace that > you are in.
Beware that this netnsid is only valid in the net name space that the 'ip' command ran in. It is not a global identifier and it is not valid in another net name space. In other words, ptp4l can't return a netnsid valid in the pmc net name space (without doing gross and unreliable hacks). > > Hmm. It's plausible the pmc instance wouldn't even know about the > > device, but ptp4l itself doesn't know whether to hide that info or > > not. Other way around could be that ptp4l is inside a namespace while > > pmc is not, but again it's not obvious. Every process is in exactly one net name space. There are no processes that are not in a net name space. There is a root net name space that is a bit special in some situations but it basically boils down to that it cannot be deleted. From a point of view of a process, there's nothing different about it. A net name space is a net name space. > ptp4l already has a public API to obtain the device name: the VLA > itself. There just isn't an easy way to invoke that interface. So we > don't have to concern ourselves with whether to hide the interface name > itself, that ship has sailed. If the API is so hard that it's not in use in practice, it makes a difference. > About the namespace--as an unprivileged process you can't just ask about > netns ids of random processes. So whether to allow ptp4l to give up this > information is a good question, because that might go against the > intentions of the admin of the machine. It also does not work, see above :-) > Maybe just documenting the issue is all that can be done. Could be. > I'm not sure I agree the process inside the namespace should be > disallowed from knowing it is. I'm not really well versed in network > namespaces, but looking at what "ip netns id" is doing under the hood it > looks like the kernel has interfaces to just tell you (RTM_GETNSID). Since every process is in a net name space (and exactly one net name space), it already knows by definition that it is in a name space :-) Whether referencing into other net name spaces makes sense or not, depends on the use. I'd argue that a daemon (such as ptp4l) should not mess with name spaces, as it needs the administrator to be able to run it in whatever net name space they chooses. But it can certainly query it if it is needed for proper interoperability. Jiri _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
