Right now service ports are defined in a single file /etc/services This causes problems as the setup rpm really wants to own this file (if it doesn't control it there's no way to gracefully add new services on upgrades) Unfortunately that means any entry the sysadmin puts in there will be erased on upgrade. Likewise if a service is trimmed to simplify the file the corresponding description will disappear So it would be really nice if an /etc/service.d existed where packages and sysadmins could put definitions that wouldn't be overwritten every time the setup package is updated Appart from making wore work for sysadmins the current situation is a security risk. services are read by iptables. If you add an iptables rule that uses a service name that is later removed from /etc/services during a setup upgrade, the iptables service will fail on startup, leaving the system wide open if the sysadmin does not notice the failure at once. Creating an /etc/services hierarchy is the solution proposed by Owen Taylor in bug #133683
This would require changing glibc's implementation of getservbyname, which I suspect is unlikely to happen. Bouncing there first.
This makes not much sense. The /etc/services file should only ever contain the officially assigned numbers. I'm sure that we are not distributing a file with all the recent additions but that's a different problem. Adding local definitions in the file is pure madness since every single machine would have to be modified. Instead, for this the NIS/LDAP services should be used.
Typical usage is you install a daemon that talks on port XXX You need to open the local firewall so clients can actually connect to this port. So you just dump a descriptive name in /etc/services and add an iptables rule that uses this Clients OTOH don't need to do anything since the default rules will let them connect to any outbound port Why would you need NIS/LDAP to define a port on a single system ?
If you object to a whole /etc/services.d/ directory could we at least have and /etc/services containing "official" Red Hat - blessed services names and a /etc/services.local containing local names ?
I knew this bogus "what about one system" argument comes up. You completely miss the purpose of this file. It has once been imagined to synchronize the use of named service ports accross multiple systems. If this isn't the case, i.e., it's only a local system, there is no point in using this file. And if distributed systems are used it only ever makes sense to either have an officially assigned number or use the same number from multiple places using services like NIS and LDAP. There will be no addition to glibc for /etc/service.d nor /etc/service.local. Neither makes _any_ sense. Period.
However - addition of local names is explicitely encouraged by the current file and all its previous versions (they all end with # Local services) - if this file is just for assigned names, where are you supposed to put private name definitions ? And don't tell me because they're not "official" you have to hardcode port numbers everywhere - NIS and LDAP are way overkill for this, besides when you're in a DMZ the last thing you want is all your servers depending of an external LDAP/NIS service Your comments show you believe local definitions has no place in this particular port table. Fine by me. I'm proposing to put them elsewere - you should be happy about it. If you don't provide some place to put them they'll stay in /etc/services like now with all the problems that causes.
Alternatively, if you insist that local names should not exist, should I file a bug on the setup component every single time I encounter a service not referenced in /etc/services ? I'm sure Bill Nottingham would be delighted to learn this.
The file only contains official numbers. If there is a file from IANA it should be updated before a release. And stop reopening this bug.
Allright You don't want local services in the current file, you don't want to provide any other place where to put them, you don't even want to know why people need this. Since in the real world local services exist, they'll be put in the current file like now. With triggers fighting for control of this file. And Red Hat support cleaning up the mess. Don't come crying later app writers and packagers don't respect your beautiful guidelines. They can only work with what you give them - if it's inadequate, it'll be abused
Ok, now that we've heard the opinion of the glibc people, that iptables should depend on external NIS/LDAP to setup it's filtering rules, what is the next step ? Create a library separate from glibc dedicated to reading a local service table somewhere ? Try to manage the current situation by having several packages poking at the same file ? Wait for firewalls to be silently disabled and have people change to a more secure OS ?
Well, if you *reaaaaaaaaally* wanted to have something like services.d, you could cook up a custom NSS module that would read it and set nsswitch to use that. But that would be somewhat overkill.
Ok. Then we're back to square one -> make /etc/services noreplace since we've shown it's not likely there will be another place to put local services in the short term, and if you put local services in /etc/services blindly replacing it on upgrades may kill your firewall. That, or adding a lot of smarts to iptables so an iptable initialisation failure blocks network startup. Or maybe load the iptables rules that work and ignore the others instead of failing completly like now. /etc/services noreplace was always the quickest fix, it would have been nice to make this workaround unecessary though
services has been noreplace since: * Mon Sep 27 2004 Rik van Riel <riel> 2.5.34-2 - mark /etc/services config(noreplace) (#133683) If you wanted a custom NSS module, there *is* nss_directories, available from http://people.redhat.com/nalin/testing/. But that's rather experimental.
I'll close the two bugs then. noreplace was whet I asked for in the first place, this RFE was just an attempt to find a clean solution