Re: dpkg-statoverride vs. suidmanager

[Joey Hess <joeyh@debian.org>]

Wichert Akkerman wrote:
> Previously Petr Cech wrote:
> > so if it checks, then all you need to do is NOT convert, when you encounter an
> > old dpkg
> 
> you mean call suidregister/unregister conditionally depending on the
> version of dpkg installed? I guess you can do that; it does complicate
> the maintainer scripts though.

No, that won't work. Consider:

1. Package foo is installed, with binary bar, that is suid by default,
   but I have overridden to remove all suidness because I consider that is a
   security hole.
2. Foo is updated for statoverride support. This means that bar is now
   suid inside the deb file itself.
3. I upgrade foo. The package is unpacked. Bar is now suid.

4a. Foo's postinst is run. Since I have not yet upgraded to a dpkg that
    supports statoverride, the old suidregister stuff fires, removing the
    suid bit as I told it to.
 or
4b. Foo's postinst is run. Since I have upgraded to the new dpkg the
    other day, the suidregister stuff calls statoverride, removing the
    suid bit as I told it to.

Unfortunatly, between 3 and 4a or 4b, there is a (possibly long) window
where bar is suid, against my express wishes.

Now we could not ship bar suid in the deb and just let
suidregister/statoverride make it suid in the postinst, but then we have
lost most of the gain of statoverride.

-- 
see shy jo