Page MenuHomeFreeBSD

Update /etc/services: attempt to bring it to the new century
Needs ReviewPublic

Authored by pfg on Tue, Feb 11, 4:46 PM.

Details

Reviewers
tuexen
cy
vangyzen
Summary

Remove references to Kerberos IV: it's EOL since long ago.
Use the same order as upstream: tcp, udp, then sctp.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 29346
Build 27245: arc lint + arc unit

Event Timeline

pfg created this revision.Tue, Feb 11, 4:46 PM
mjg added a subscriber: mjg.EditedTue, Feb 11, 7:00 PM

Removing very stale entries or adding something may be fine, but the list as suggested is a non-starter. One has to expect there is plenty of custom userspace code parsing it which will choke on the new size.

Ubuntu 18.04 has the file only at 591 lines, which means FreeBSD is already pushing it with 2496 lines. So imo if anything we should be looking at trimming the list to be closer size-wise to what they ship in Linux.

pfg added a comment.Tue, Feb 11, 7:33 PM

Hello;

In D23621#518513, @mjg wrote:

Removing very stale entries or adding something may be fine, but the list as suggested is a non-starter. One has to expect there is plenty of custom userspace code parsing it which will choke on the new size.

I do agree there is some crap that we don't care about: things like flex-lm licensing or some services that I suspect have died and were never de-registered at IANA. Some other things like vnc-server I happen to have used a lot and I was surprised we never carried.

Ubuntu 18.04 has the file only at 591 lines, which means FreeBSD is already pushing it with 2496 lines. So imo if anything we should be looking at trimming the list to be closer size-wise to what they ship in Linux.

Well, the list that NetBSD carries, and was partially used as reference, is 21838 lines. What is the use of a database if it has to be short ? ;).

mjg added a comment.Tue, Feb 11, 7:59 PM

If you want an example of what happens when a random parameter gets whacked out of proportion compared to Linux, here it is:

https://www.postgresql.org/message-id/CAEepm%3D3VF%3DPUp2f8gU8fgZB22yPE_KBS0%2Be1AHAtQ%3D09schTHg%40mail.gmail.com

Parameter set to 65536 because "why not" while it is 4096 on Linux resulted in a 256KB buffer in postgres when it should have been a fraction of that size. And so on. If there is no reason to deviate, don't.

I'm afraid NetBSD doing something is not an argument.

cy requested changes to this revision.Tue, Feb 11, 8:30 PM

The fact that Kerberos IV is EOL doesn'[t mitigate the fact that the entries are still registered with IANA and that some KRB4 app may expect the entries to exist. Suggest we use https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml as a reference.

This revision now requires changes to proceed.Tue, Feb 11, 8:30 PM
pfg added a comment.Tue, Feb 11, 8:53 PM
In D23621#518528, @mjg wrote:

If you want an example of what happens when a random parameter gets whacked out of proportion compared to Linux, here it is:
https://www.postgresql.org/message-id/CAEepm%3D3VF%3DPUp2f8gU8fgZB22yPE_KBS0%2Be1AHAtQ%3D09schTHg%40mail.gmail.com
Parameter set to 65536 because "why not" while it is 4096 on Linux resulted in a 256KB buffer in postgres when it should have been a fraction of that size. And so on. If there is no reason to deviate, don't.

This is different, plus the change of size in the services file is an order of magnitude smaller. Comparing to linux is not always a good idea either.

I just looked at the services in ubuntu/debian and they haven't updated in a while. They use as a reference the FreeBSD file when we were using CVS.

Another linux source for the /etc/service file is here:
http://sethwklein.net/iana-etc (which is what NetBSD follows)

I'm afraid NetBSD doing something is not an argument.

The above change is not an argument either not updating things either.

Let me do some revision here to drastically reduce the size. I basically do agree that we shouldn't add crap anywhere for the matter of change, but it shouldn't be that we have to hunt for services table when you have one in the system.

pfg added a comment.Tue, Feb 11, 9:00 PM
In D23621#518545, @cy wrote:

The fact that Kerberos IV is EOL doesn'[t mitigate the fact that the entries are still registered with IANA and that some KRB4 app may expect the entries to exist. Suggest we use https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml as a reference.

I did check the IANA ports number database :). The Kerberos IV numbers I removed are not registered in IANA any more.

Kerberos IV was not only EOL'd in Oct 2006:
https://web.mit.edu/kerberos/krb4-end-of-life.html

It's use is a security risk.

cy accepted this revision.Tue, Feb 11, 11:30 PM

If they've been removed from IANA's list, then that's OK. To be absolutely correct, using KRB4 is a security risk, however allowing them to stay in services(5) is not a risk. It's KRB4 that is the risk. I'll accept this revision as long as the commit message *accurately* reflects that we are truing up our services(5) with IANA, not the documentation of a port is itself a security risk, which it is not. Just so we are clear about how this is documented in the commit message.

This revision is now accepted and ready to land.Tue, Feb 11, 11:30 PM
pfg updated this revision to Diff 68247.Thu, Feb 13, 3:33 PM

Update Take2:
It is important to consider the differences between System Ports and User
ports. This changes keeps the system ports closely in sync with IANA.

For the users ports we can keep only those that are vaulable, ignoring a huge
amount of transitory services used by commercial applications to register.
I looked at the OpenBSD list which is reasonably sized as a further reference.

This revision now requires review to proceed.Thu, Feb 13, 3:33 PM
pfg updated this revision to Diff 68248.Thu, Feb 13, 3:54 PM

Sync with latest updates.