Re: dpkg-statoverride vs. suidmanager

[Joey Hess <joeyh@debian.org>]

Joey Hess wrote:
> > How about dpkg 1.8 will read /etc/suid.conf and import it into the
> > statoverride database? I could do that pretty easily.
> 
> What happens to packages that continue to use suidregister after that,
> though? I guess suidregister in the postinst will override statoverride.
> So:
> 
> 1. foo is suid by default, and suidregistered
> 2. dpkg upgrade happens, so it is not statoverridden to suid
> 3. user makes foo non-suid, updates /etc/suid.conf
> 4. foo's package is converted to just use statoverride, so the changes
>    from 3. are lost.

I have a new idea... If dpkg does the conversion as a flag day, then it
could also conflict with suidmanager. Thus, suidmanager will be removed
(have to make sure it leaves permissions of the managed files alone, but
I'd suppose so), dpkg's preinst can snarf the suid.conf file, and the
postinst or something can convert it over and call statoverride.

This seems like it would work, iff we can preserve the suid.conf file
after suidmanager is gone. Another possibility would be to make a new
suidmanager that simply converts to statoverride when you upgrade to it,
and then deletes the suid.conf file. Make dpkg conflict with all earlier
versions of suidmanager. This new suidmanager would not include a
suidregister script, so postinsts do not try to call that.

-- 
see shy jo