SUN RPC NUMBERS To obtain SUN Remote Procedure Call (RPC) numbers send an e-mail request to "email@example.com". The RPC port management service ('portmap' in SunOS versions less than 5.0 and 'rpcbind' in SunOS versions greater than 5.0) "registers" the IP port number that is allocated to a particular service when that service is created. It does not allocate ports on behalf of those services. For an exact specification of the semantics refer to the source code of svcudp_create() and svctcp_create() in the archives. In short however is that these interfaces, and svc_tli_create their Transport Independent RPC equivalent, take either a user specified port number or RPC_ANY (-1) which effectively means "I don't care." In the "I don't care" case the create code simply calls socket(2) or t_open(3n) which allocates an IP port based on the rules: if euid of the requesting process is 0 (i.e., root) allocate the next available port number in the reserved port range. else allocate the next available port in the non-reserved range. Port numbers count up sequentially. Can a port that is "assigned" can be used when the assignee's service is not present? Say port 501 is assigned to the "jeans" service. On a machine that does not have the "jeans" service, nor has any clients that might be expecting to use it, is port 501 available for other uses? Any dynamic allocation process, like the portmapper, that chooses the next unused port might allocate port 501 dynamically to a process that asked for a "I don't care" port. So any dynamic allocation scheme may pick an unused port that happened to correspond to a port number that had been "assigned" but was currently unused. While it might be desirable, it is impossible to guarantee that any unused port, even though officially assigned to a service, is not picked by a dynamic allocator since such an assignment might occur long after the delivery of the system into a site that doesn't watch for the latest list. There is the restriction that only "superuser" on BSD derived systems such as SunOS can bind to a port number that is less than 1024. So programs have used this information in the past to identify whether or not the service they were talking to was started by the superuser on the remote system. Making this assumption is dangerous because not all system enforce this restriction. Sun RPC services use ports that are currently unused. If someone noted that an RPC service was using port 781, it would be just as happy using port 891, or 951. The service doesn't care what port it gets, remote clients will query the portmapper to ask it what port number was assigned to the service when it was started. The key is that the port was not currently in use. The only port that ONC/RPC must have is 111 its assigned port for the portmap service. The most common complaint comes when people put a new service on their system. When they configure their systems they put the new service configuration commands at the end of their system startup scripts. During startup, several network services may be started. Those services that are ONC/RPC based just pick the next available port, those that have pre-assigned ports bind to their pre-assigned port. Clearly the correct sequence is to have all services that need a particular port to be started first (or if they are "latent" services that are started by inetd, to have inetd started). Finally, the RPC services should be started as they will be assigned unused ports. (In the BSD networking code (which we use) the algorithm for picking ports is in the file in_pcb.c, function in_pcbbind().) Services should be started in this order: a) Services that will "run" continuously and have an assigned port. Note that this includes rpcbind (nee portmap) that has port 111 assigned to it. b) inetd - which will automatically create sockets for those services that have reserved ports but only run on demand (like finger) c) RPC services - which will automatically pick unused ports and maximize efficiency of the "IP Port" namespace. The include file /usr/include/netinet/in.h defines a constant IPPORT_RESERVED to be 1024. The relevant text is: /* * Ports < IPPORT_RESERVED are reserved for * privileged processes (e.g. root). * Ports > IPPORT_USERRESERVED are reserved * for servers, not necessarily privileged. */ #define IPPORT_RESERVED 1024 #define IPPORT_USERRESERVED 5000 Portmap does not allocate ports, the kernel allocates ports. The code that does this is part of nearly every UNIX system in the world (and since the BSD code is 'free' it is often the same code). RPC services ask the kernel to allocate them a port by calling the "bind()" system call. The parameter they pass is "INADDR_ANY" which means "allocate me any IP port you want". The kernel does that by looking at all of the ports that are currently in use and picking one that is not currently used. The number picked is either less that 1024 if the process is privledged, or greater than 1024 if the process is not privledged. After the kernel has allocated a port, the service registers this allocation with portmap. The portmapper is merely a registry of previously allocated ports. Note "allocated" here is being used in the sense that they are used by an open socket, not assigned a well known name. The role of /etc/services is to provide an idea to people who are looking at network traffic as to where a packet may have originated from or is headed to. For services like finger that have assigned ports, they can just hard code the port they want into their executable. (it isn't like it will change, and if they read it from /etc/services and someone had mistyped the port number it won't interoperate with clients anyway!) It is not practical to read the /etc/services file into the kernel to prevent it from giving out port numbers that are "pre-assigned", nor is it generally desirable since with the correct ordering of startup it is completely unneccesary. Editors Note: This information was supplied by Chuck McManis of Sun.