Radoslaw I think we can assume that the case being discussed here is a "client" program which is using the a name for the "server" to be contacted and, hence, needs to call gethostbyname() in order to "resolve" the name into, strictly, a list of IP addresses, where the list may well have only one member. Had the "client" program used an IP address as the parameter used to access the "server", no gethostbyname() call would be necessary.
Thus, on behalf of the "client" program, the "resolver" address space accesses the "resolver configuration file' in order to discover how to resolve the name. First it checks the LOOKUP parameter in order to discover whether "local hosts tables", name servers or both are to be used and, if both, in what order. If name servers need to be used, some "resolver configuration file" parameters will be used in order to perform the search of name servers. If "local host tables" need to be used, there will be access of the files as identified by search order defined by the type of "environment" and the "resolver setup statements". In the case being discussed it appears that the "local host tables" needed to be consulted. Given your concern about the significance of what can be accessed, it's interesting to reflect that, if "read" access is granted to all the "resolver" data sets. then it the following notes from a "sockets" presentation show that whole data sets can be read using socket calls: <quote> Sequential Data Lookup Subroutines Get structure pointer sequentially code <--- setXXXent(stayopen) &XXX-structure <--- getXXXent() void <--- endXXXent() XXX is host net - for network proto - for protocol serv - for service setXXXent opens the data set getXXXent returns pointers sequentially endXXXent closes the data set, if necessary stayopen zero - close data set after call non-zero - keep data set open after calls </quote> I don't suppose much advantage is to be gained from knowing the contents of the "protocol" and "services" data sets - they are pretty much standard - but there may be some advantage in knowing what is to be found in the "local host tables" data set. Chris Mason ----- Original Message ----- From: "R.S." <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Wednesday, 22 November, 2006 6:18 PM Subject: Re: TCPIP Racf Protection for application? > Rick Fochtman wrote: > > --------------------------<snip>-------------------- > > > >>> RACF people don't like to grant generic READ permission to all users. > >>> > >>> > >> Why not? What's the harm? > >> > >> > > -------------------------<unsnip>------------------------------ > > I agree. Some datasets should be granted generic READ access, or even > > GLOBAL READ access. The various ISPF datasets, like panels and > > skeletons, come to mind as excellent examples. Sometimes efficient > > operation is more important than having a tight lock on security, > > especially if it's affecting a large community of users. > > > > And you'll find that judicious use of the GLOBAL DATASET profile can > > considerably reduce the I/O activity on the RACF database and also > > reduce some of the huge volume of SMF data that's created in a > > medium-to-large shop. > > I don't want to vote what's good for this case (tcpip configuration > files), however I see big difference between ISPF stuff, help, books and > any configuration files. The first provides virtually no information > about your system, while the second provides some information. > > The matter of discussion is whether such piece of configuration should > remain secret or not. Sometimes yes, sometimes not. It depends. YMMV. > Recently we had question about VTAMLST access (it was locked), some time > ago question about PARMLIB was asked, etc. etc. > From one hand people say security by obscurity is no security. From the > other hand, it is easier to find some hole, when you know details about > the system. > > Regards > -- > Radoslaw Skorupka > Lodz, Poland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
