[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf



On Mon, Aug 17, 2009 at 04:18:13PM -0700, Steve Langasek wrote:
> On Sun, Aug 16, 2009 at 09:55:29PM +0200, Serafeim Zanikolas wrote:
> > Package: debian-policy
> > Version: 3.8.2.0
> > Severity: normal
> 
> > Hello policy makers :)
> 
> > update-inetd is seriously bug infested, IMHO to some extent because of the
> > issue below.
> 
> > Policy 11.2 says:
> 
> >     If a package wants to install an example entry into `/etc/inetd.conf', the
> >     entry must be preceded with exactly one hash character (`#').  Such lines
> >     are treated as "commented out by user" by the `update-inetd' script and
> >     are not changed or activated during package updates.
> >     [presumably, "not changed" here implies also "not deleted"]
> 
> > Effectively this means that we cannot distinguish between two entirely
> > different things: local-admin-policy and examples generated by postinst
> > maintainer scripts.
> 
> > Now how does this lead to bugs? Say I install ftp-daemon-a, which adds an
> > example entry to /etc/inetd.conf, and then I uninstall the package.  The
> > example entry will survive the package's removal (even if prerm calls
> > update-inetd, it won't be removed because it's indistinguishable from
> > local-admin-policy).
> 
> > Then I decide to install ftp-daemon-b. If the package's postinst calls
> > update-inetd to enable the new service, the new entry won't be added because
> > it's apparently local-admin-policy that ftp should be disabled.
> 
> > A potential fix would be to prescribe that example entries added by maintainer
> > scripts are preceded with '#<example># ' (to be consistent with '#<off># '
> > which is what update-inetd uses by default to denote disabled entries).
> 
> I would suggest disallowing example entries altogether; let packages use the
> '#<off>#' syntax instead.  Or is there some reason I'm missing why we would
> want to support so many different ways for packages to add lines to
> update-inetd?

I would really rather we went with the proposal I put forward in this
thread:

http://lists.debian.org/debian-devel/2009/03/msg00496.html

in this message:
http://lists.debian.org/debian-devel/2009/03/msg00573.html

This is a relatively simple task, just one that needs a reasonably
labour-intensive transition over a few releases of the fixed update-inetd
package
1) Add functionality to process fragments in addition to command-line args.
2) Update all packages calling update-inetd to ship a fragment.
   At this point both the old and new mechanisms will still work, with the
   inetds using /etc/inetd.conf.
3) Switch inetds to use the appropriate generated config file.
4) Update all packages to remove use of update-inetd with arguments
   (maybe make it into a dpkg trigger?)
4) Remove old update-inetd code to leave only new clean and simple code.
   At this point, /etc/inetd.conf is obsolete and unused.

Unfortunately, I lack the time to write the code and push this forward,
otherwise I would have tried to get this done for Squeeze.  But it's
not technically difficult to do, it just needs time.

The advantage of this approach is that is removes *all* of the many
update-inetd bugs by throwing the whole mess into the bin.  It should
also allow a smooth transition, though the above example plan doesn't
account for migrating active settings over to the new config file
fragments.  It shouldn't be too hard to do.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.



Reply to: