Bug#118646: Not just a dpkg/run-parts problem

[Steve Greenland <steveg@moregruel.net>]

Uh-oh. Houston, we have a problem. This change has widespread effects,
or at least wider than is apparent from the bug history. I've sent this
to the BTS as well as debian-devel to encourage the dpkg developers
to NOT implement this change in dpkg until we agree on what the final
solution should be. 

For those who haven't read the bug 118646, it involves a significant
behavior change in Debian systems. For a long time, programs that
process (run, read, whatever) every file in a directory have skipped
over files containing '.' and other characters, primarily to accommodate
dpkg's (and other debian tools) technique of storing variations of foo
under foo.distrib, foo.dpkg-dist, etc. The run-parts program defined
the defacto rules: valid filenames contain only alphanumerics and the
'_'. However, the LSB appears to encourage/require/whatever that certain
classes of files contain the domain name, which contains periods.
Therefore run-parts will be (has been?) changed. From the bug log, it
appears that the approach is to check for explicit extensions, either
from dpkg managed files, (e.g. .dpkg-new) or from some list of "common
backup extensions".

While I agree that there needs to be some solution to accommodate the
LSB, I think this is a bad approach. One problem is that battle over
what extensions to exclude will be neverending (I say this as the
person who has to manage the list of filesystem types excluded from
checksecurity, and note that there's already been at least one addition
to the run-parts list since the initial change was made), and (more
significantly) that there are programs besides run-parts that need to
enforce the same set of rules, cron's handling of /etc/cron.d being the
one that leaps to *my* selfish mind, but I'm sure that there are others.
Combine these issues, and I can almost guarantee that there will never
be a completely consistent set of programs/rules.

I see two possible solutions:

1. An algorithmic specification of valid vs. invalid filenames, possibly
with a limited, never-to-be-extended set of "invalid" extensions to
accommodate existing systems. This solves both problems, so long as
it is specified in policy (not just "however run-parts does it"). Of
course, everyone doing this kind of processing has to implement it, but
only once.

2. Provide a library function that takes file name and returns
valid/invalid, along with wrappers for perl, python, java, sh, etc. This
solves the second problem, and puts all the onus of the gatekeeping
onto one central source. It will be a PITA for *someone*, but at least
everybody will use the same method. I suppose that SWIG could be used to
generate the wrappers, so it wouldn't be too painful.

Or maybe I'm wrong, and run-parts and cron are the only two things in
the entire Debian archive that need to worry about this, in which case
I'll work with the maintainer to make sure we keep a consistent list.

Of course, none of this solves the problem that a good many of us have
relied on the ability to deactivate a particular file by putting a
period in the name, and this significant behavior change in run-parts
was made with no public announcement beyond a cryptic changelog entry,
and it would be *really* nice if this behavior change only occured for
people who have installed the LSB compatibility system (which would be
fairly easy to implement with a standard library that got diverted), but
I suspect we're screwed.

Steve

-- 
Steve Greenland

    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world.       -- seen on the net