Comment 11 for bug 317944

On Mon, Jan 19, 2009 at 12:01:23PM -0000, Scott James Remnant wrote:
> On Mon, 2009-01-19 at 08:51 +0000, Matt Zimmerman wrote:
>
> > > Do you think something might have actually done "find | chmod" and
> > > escaped and run across /dev for some reason?
> >
> > I've looked around the filesystem a bit, and nothing looks out of the
> > ordinary outside of /dev.
> >
> > You can see in the stat output that only the ctime changed, so it's the
> > original device node which was created by udev, but has been mangled by
> > something.
> >
> The /dev/.udev/db have been touched as well, which heavily implies that
> udev was triggered.
>
> With the rules being moved, it is possible that the trigger would reset
> the permissions to 0660.

Why would a trigger set the permissions to 0660 when the udev rule calls for
0666?

> > > Do you happen to have system logs from the upgrade time, there may be
> > > messages that give us a clue what happened.
> >
> > I have the dist-upgrader logs which look fairly complete, and will attach
> > those. The timestamps in the log confirm that the ctime on /dev/null was
> > during the upgrade, and narrows down the possible packages (somewhere from
> > netbase to gsm-utils):
> >
> Notably udev isn't in this list.

It definitely seems as if this happened when running maintainer scripts from
the Jaunty packages, so whatever did this is still lurking out there.

I'm currently grepping through the package contents for anything suspicious.
One thing which caught my eye was the new LSB init script dependency
comments (e.g. Required-Start: udev in pcmciautils). Could these have
caused the udev init script to be run somehow?

--
 - mdz