Jiri Benc <jb...@redhat.com> writes:
> 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). I was actually thinking about /var/run/netns being mounted elsewhere or some such, which would prevent "ip netns id" from working. The symbolic names seem to be accessible from other namespaces just fine --"ip netns exec foo ip netns exec bar bash" works-- but renaming /var/run breaks it. I'm probably just missing something, I haven't worked with network namespaces much. >> 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. Yeah, conceded, random admins probably wouldn't do this. >> 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 :-) Agreed. >> 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. > >> Maybe just documenting the issue is all that can be done. > > Could be. I don't have other ideas than this. I also think that having an easy to use way to access the interface outweighs the risks. _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
