xinetd enabled is not overruled by disable in service declaration

[Klaus S. Madsen]

Binary package hint: xinetd

With a standard installation of xinetd, I added the line:

enabled = chargen-stream

to the defaults part of /etc/xinetd.conf. The disable = yes line is still present in /etc/xinetd.d/chargen.

After restarting the xinetd service, the chargen service is suddenly available. This clashes with the man-page description of enabled:

       enabled Takes a list of service ID's to enable. This will
                        enable only the services listed as arguments to this
                        attribute; the rest will be disabled. If you have 2
                        ftp services, you will need to list both of their ID's
                        and not just ftp. (ftp is the service name, not the
                        ID. It might accidentally be the ID, but you better
                        check.) Note that the service "disable" attribute and
                        "DISABLE" flag can prevent a service from being
                        enabled despite being listed in this attribute.

I'm using xinetd-2.3.14-5 on Ubuntu 8.04.1 and xinetd-2.3.14-0ubuntu1 on Ubuntu 6.06LTS. I have also tested xinetd-2.3.14-115.1 from openSUSE 11.0 and xinetd-2.3.14-10.el5 from CentOS. The SuSE one works as the man-page describes, while the CentOS works in the same way as the Ubuntu one. I haven't tested an unmodified upstream.

Note: I've marked this as a security problem, as the user might think that a specific service is disabled, while in reality xinetd still enables the service.

[Jamie Strandboge (jdstrand)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Chuck Short (zulcss)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/. Thanks again and we appreciate your help.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

I've tested it, by downloading the Karmic Koala Kubuntu beta live image, running apt-get update, and then apt-get install xinetd to install the xinetd daemon.

Altering the /etc/xinetd.conf file as described in the original bug report, still enables the chargen service. I also verified that the documentation still states that the "disable = yes" line in the service configuration takes precedence.

So this bug is still present in Karmic.

[Chuck Short (zulcss)]

Thanks for the bug report. Setting this to confirmed.

Regards
chuck

[LtWorf (tiposchi)]

Where in the documentation does it say that the disable = yes takes precedence?

In the quoted text:

Note that the service "disable" attribute and
                        "DISABLE" flag can prevent a service from being
                        enabled despite being listed in this attribute.

It _can_ prevent a service from being enabled, but not it _will_, meaning that no deterministic behaviour is indicated for this case.

[Klaus S. Madsen (ubuntu-hjernemadsen)]

I reported it because I believe that disable should take precedence from my reading of the man-page. Furthermore making disable overrule enable is the most secure thing to do if there is any ambiguity about whether a service should be enabled or disabled in the configuration file.

If you have read the entire man-page and determined that my understanding is wrong, please feel free to close the bug. I have no need to argue further about a 5 year old bug-report that no one has looked at in 4 years, and which exists in a piece of unloved legacy software.

[Launchpad Janitor (janitor)]

[Expired for xinetd (Ubuntu) because there has been no activity for 60 days.]