Bug 171906 - RFE Make iptables and friends read service descriptions in /etc/services.d
RFE Make iptables and friends read service descriptions in /etc/services.d
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brian Brock
:
Depends On:
Blocks: 133683 FC5Target
  Show dependency treegraph
 
Reported: 2005-10-27 13:30 EDT by Nicolas Mailhot
Modified: 2014-03-16 22:56 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-01 11:46:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2005-10-27 13:30:37 EDT
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
Comment 1 Bill Nottingham 2005-10-27 14:44:23 EDT
This would require changing glibc's implementation of getservbyname, which I
suspect is unlikely to happen. Bouncing there first.
Comment 2 Ulrich Drepper 2005-10-31 10:16:48 EST
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.
Comment 3 Nicolas Mailhot 2005-10-31 10:24:24 EST
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 ?
Comment 4 Nicolas Mailhot 2005-10-31 10:27:58 EST
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 ?
Comment 5 Ulrich Drepper 2005-10-31 10:32:44 EST
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.
Comment 6 Nicolas Mailhot 2005-10-31 10:42:45 EST
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.
Comment 7 Nicolas Mailhot 2005-10-31 11:09:31 EST
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.
Comment 8 Ulrich Drepper 2005-10-31 11:31:45 EST
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.
Comment 9 Nicolas Mailhot 2005-10-31 12:34:22 EST
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
Comment 10 Nicolas Mailhot 2005-10-31 13:33:37 EST
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 ?
Comment 11 Bill Nottingham 2005-10-31 15:23:49 EST
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.
Comment 12 Nicolas Mailhot 2005-10-31 15:53:02 EST
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
Comment 13 Bill Nottingham 2005-11-01 11:39:23 EST
services has been noreplace since:

* Mon Sep 27 2004 Rik van Riel <riel@redhat.com> 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.
Comment 14 Nicolas Mailhot 2005-11-01 11:46:25 EST
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

Note You need to log in before you can comment on or make changes to this bug.