Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Mon, 03 Dec 2012 17:54:43 -0600

On 12/3/12 11:51 AM, Andrew Johnson wrote:
> Hi Lewis,
> 
> On 2012-12-03 J. Lewis Muir wrote:
>> Would you be willing to change the default behavior to act as if the
>> CAJ_STRIP_HOSTNAME system property had been set to true?  If the
>> underlying implementation is broken and returns an FQDN where it should
>> not, and if you don't do anything to correct that in CAJ, then CAJ will
>> be using a hostname that will not work with Access Security.  No one
>> wants that.
> 
> IMHO CAJ should try to provide the IOC/server with exactly the same name that 
> the C++ CA client library gives when run on that machine, which could be the 
> short name, a FQDN or even some intermediate name.  Where the name comes from 
> can vary with different OSs, different versions of the C run-time library, and 
> may depend on what's in the machine's /etc/hosts file or even host its DNS 
> service is configured.
> 
> It looks like the C++ library gets the name using the class localHostName in 
> src/ca/localHostName.cpp which calls the C run-time library's gethostname() 
> function.  On Linux that apparently returns the node-name from uname(2), but 
> other OSs may implement it differently.  Read the NOTES to the RHEL manpages 
> on uname(2) for a discussion about the node-name field.

Hi, Andrew.

This is problematic because the Java API for retrieving the hostname
does not specify that the value comes from the C run-time library's
gethostname() function.  So, for CAJ to remain a pure Java
implementation, there is no good way for it to match the C++ CA client
library's behavior since the C++ CA client library's behavior is
determined by the C run-time library's gethostname() behavior.

Matej said he didn't like the idea of invoking the hostname command in a
subprocess, but that might be the closest we could get to matching the C
run-time library's gethostname() behavior while still remaining pure
Java.  (And of course it would have to fall back to the Java API when
the hostname command is unavailable or exits with a non-zero status.)

To do better here, I think the access security mechanism would need to
be rethought, and the behavior of the C++ CA client library would need
to be redefined to not depend on the C run-time library's gethostname()
behavior.

Doing this would of course help CAJ, but it would help other platforms
too.  I'm a little surprised this hasn't come up before, but maybe
people aren't using the access security mechanism across a wide range of
platforms.  The fact that the C++ CA client library can give such a wide
range of names (as you said, short name, FQDN, or intermediate name)
suggests it would run into problems fairly quickly with a heterogeneous
set of platforms.

> Note that shortening the name could have security implications at some sites, 
> so I don't like the idea of doing that inside the CAJ implementation.  If both 
> CA libraries /can/ be made to return the same name then at least an IOC's 
> access security file only needs one name per host, but you can always list 
> both names in the HAG if Java doesn't provide access to the gethostname() 
> function.

Right; I was aware of that "security" issue.  I only suggested
shortening the name given that Matej said that EPICS CA wanted the short
name.  But from what you're saying, that's not true.

Of course this whole business of access security based on a hostname
that the client provides to the server is pretty silly.  Why doesn't the
server obtain the source IP address of the CA client request, convert
that into a hostname, and perform the hostname matching for the access
security?

Thanks,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System