Keller, Jacob E <jacob.e.kel...@intel.com> writes:
>> From: Petr Machata [mailto:pe...@mellanox.com] >> Sent: Friday, September 13, 2019 7:58 AM >> To: Jiri Benc <jb...@redhat.com> >> Cc: linuxptp-devel@lists.sourceforge.net >> Subject: Re: [Linuxptp-devel] [PATCH 2/2] pmc: Support querying >> TLV_PORT_PROPERTIES_NP >> >> Jiri Benc <jb...@redhat.com> writes: >> >> > pmc is different. It's not tied to the service start time, it's used by >> > administrators and by various scripts from varying environment. While >> > you can reasonably expect that ptp4l and phc2sys will be run in the >> > same name space, it's not necessarily the case for pmc. >> >> Hmm, and as an end user I can't do `ip netns identify $(pidof ptp4l)` >> even if I know about this issue. >> >> Maybe ptp4l could include the namespace name in the VLA response. Are >> the messages considered a stable API? >> > > Is the namespacing information supposed to be kept secure from > processes inside the namespacing? I would want to prevent any sort of > leak of namespace info in that case. ptp4l won't be able to tell the > request came from within a namespace either. Inside the namespace you can do "ip netns id" to get the namespace that you are in. > 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. 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. 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. Maybe just documenting the issue is all that can be done. > I'm not sure what the best practice here is. Yeah, I didn't even think about this until Jiri brought it up. >> Alternatively I might mention the issue in the man page. >> >> Not being able to tell which of the PTP port identifiers represents >> which actual interface is something of a problem if you have more than >> about two of them. > > Right, but part of namespacing is that processes inside the namespace > should generally not know they are, and not be aware of anything > outside the namespace... 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). Thanks, Petr _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
