On Wed, 10 Apr 1996, Dave Roberts wrote:
> The last thing I want to do is start an O/S flame war, I think we've had
> far too many of those already. What I am looking for are bare honest
I too am not trying to start an OS flame war. However, there's something
Solaris 2.5 that I can't get proper answers to (I've been playing
telephone tag with my Sun rep) and it bothers me.
><SNIP> (proposed use of BSD/OS vs Solaris removed)
> AFAIK, the facts stand as follows (please corrent me if I am wrong).
> BSD offers the immutable flag - Solaris does not.
> BSD gives me source code - Solaris does not.
> BSD allows me to compile stuff (ls etc) with static libs - Solaris does
> not (if I remember a thread a while ago).
BSD does not have NIS integrated in every nook and cranny of the OS -
Solaris does. And now under 2.5, this may be more of a problem! Let
Last week, our web sever (an Ultra running 2.5) somehow lost its
identity. What I mean on that is that if programs were to do a uname(2)
or sysinfo(2) call to get the nodename (not the same name as the network
interfaces) and then do a gethostbyname call, it would get the address
of the "outside" (internet) network interface and not the "internal"
interface, as we want for our CGI scripts.
While I didn't put this system together, the person who did assures me
that it has been configured the same as the SS20 running 2.4 the web
server was running on. I have confirmed this. However, it seems that
there are differences and it's Solaris 2.5 causing them.
First, I found a program called nscd. If I RTFM, nscd(1M) says it's the
"name service cache daemon." Huh? I respond dumbfoundedly. Isn't bind
(in.named) supposed to do this?? But this system is not running a DNS,
so what is this for? Further reading of TFM says it will cache the
hosts database (among others) "through standard libc interfaces, such as
gethostbyname(3N)...." Can we see the building of a problem??
In trying to figure out what it is and what it is doing, I ran truss on
it (for those without Solaris or System V, truss lets you trace system
calls). While it was working I found it making a call to door_info,
door_call, and door_return. Back to RTFM to the door(2) page I find it
is a "Solaris 2.5 internal implementation detail." Oh really?? Sun
calls it "a new flavor of interprocess communication" that:is not yet
available for public consumption because the interface is still
Just to give youse guys the same laugh I got, here is the WARNING from
the man page:
Please do not attempt to reverse-engineer the interface and
program to it. If you do, your program will almost certainly
fail to run on future versions of Solaris, and may even be
broken by a patch. This document does not constitute an
API. Doors may not exist or may have a completely different
set of semantics in a future release.
The long and the short of it was that I killed nscd and restarted the
web server and the problem went away!
BTW: nscd and the door system calls are not in 2.4. And I am still
waiting for a call from Sun to explain this to me!
Does anyone out there know what it is? Is it safe? What impact on
other things am I putting on the system by not running it? What is
this new interface and why introduce it in something that can be a
potential security hole? Yea, sure they didn't tell "anyone" about it,
if I had time I would reverse engineer it to see what it does--and
belive me, if *I* can do that, anyone can!!
Back to the original question:
This seems to be a case of Sun promoting Security by Obscurity! Is this
who you want to trust your security systems to??
(OK, so I added it as a flame... but you sit here with company brass
breathing down your back wondering why they can't demo a new feature to
potential clients and see how happy you are!)
I will take any and all explanation from Sun.
(telephone number available on request)
scott barman DISCLAIMER: I speak to anyone who will listen,
com and I speak only for myself.
Java: Sun's answer to the Unix Virus!