[OPEN-ILS-DEV] transport_session.c: use of $HOSTNAME

[Scott McKellar]

--- Mike Rylander <mrylander at gmail.com> wrote:

<snip -- about using $HOSTNAME vs gethostname()>
 
> Is there a need for these to match over time?  If so, the environment
> may be safer, since the result of gethostname() may change from one
> call to the next, no?

Suppose a program needs the host name twice, whether from $HOSTNAME or
from gethostname().  If we use $HOSTNAME, we'll get the same answer
both times.  Once the process starts, nothing outside the process can
change the values of its environmental variables.  It's possible for
the process to change its own environment, but that's under our 
control.  In practice I don't see any calls to setenv().

On the other hand, the user may have changed the value of $HOSTNAME
before starting the process.  In that case we would get an answer
that was consistent but wrong.

-----------

If we use gethostname(), the answer will be correct by definition.
However it's possible for another concurrent process to change the 
host name between the first and second calls to gethostname(), and I 
presume that the second call would then get an answer different from
the first one.

In order to change the host name, the other process would need to be
running with root privileges.  I expect that it's rare for an
administrator to change the host name on a running production system,
especially if that system runs a heavily networked application.  Any
such change would probably require that he shut down any relevant
server processes or other such daemons, and maybe tinker with some
configuration files before starting them up again.  Still, it's
possible that he might miss something.

-----------

If we want consistency, and don't care about accuracy, then we should 
stick with $HOSTNAME.

If vice versa, we should use gethostname().

If we want both consistency and accuracy, we should implement an
osrf_gethostname().  Upon the first call it would call gethostname()
and cache the results.  Upon subsequent calls it would return the
results of the first call.  Those results may become inaccurate if
somebody changes the host name out from under us, but at least they
wouldn't be vulnerable to a mischievous user.

I can build the patches either way, but I need to know the 
requirements, and you two appear not to agree yet.

--------------

I don't understand all the uses to which the host name is put, but
here are my best guesses:

In transport_system.c, we use the host name in an informational 
message.  In that case neither accuracy nor consistency is terribly
critical.  However we probably care more about accuracy than about 
consistency, and should therefore use gethostname().

In osrf_system.c, we use the host name to build a resource name. Since
we also include a timestamp, we specifically don't need to build the
same resource name twice, so we don't need consistency.  We do need
accuracy, because the resource name is evidently designed to be
unique.  If a process spoofs the hostname of some other host, it
would be possible (however unlikely) for two such resource names to
collide.  Therefore we should use gethostname() here as well.

(Note that two different hosts may legitimately have the same host
name, especially if they are behind different routers.  The present
discussion does not address that possibility one way or the other.)

In osrf_chat.c we also build a string incorporating the host name
and a timestamp, and that string is presumably intended to be unique.
Therefore by similar reasoning I conclude that we need accuracy
rather than consistency here as well.

(Since we put the resulting string through an md5 hashing routine,
there is a small but finite probability that we'll get a collision
anyway.  But that chance is present no matter where we get the host
name.)

Tentative conclusion: in all cases, we care more about accuracy than
about consistency, and therefore should use gethostname().

I shall prepare some patches accordingly, if I don't hear otherwise.
In any case you can always not apply them.

Scott McKellar
http://home.swbell.net/mck9/ct/