Re: Packages' use of dpkg-statoverride
mdz@debian.org (Matt Zimmerman) wrote on 12.01.01 in <[🔎] 20010112111445.F8682@alcor.net>:
> On Thu, Jan 11, 2001 at 07:32:22PM +0100, Wichert Akkerman wrote:
>
> > Previously Matt Zimmerman wrote:
> > > As I said in my original message, to avoid a problem like this, all
> > > binaries should be shipped non-suid, and optionally overridden to suid.
> >
> > You should ship it in the most often used configuration, and set the
> > override beforehand if needed. That way you don't get unexpected breakage
> > if for some reason the install dies halfway through or takes very long.
> >
> > I've seen lots of people complain about things like ping suddenly no
> > longer being suid. statoverrides give us a way to close that window
> > of brokenness - we have to us it.
>
> It seems like we have to choose between a possible unwanted window of
> non-suidness and a possible unwanted window of suidness.
The "suddenly broken" scenario is an update. For normal upgrades, it
should simply not happen at all with dpkg-statoverrides.
If a package is broken during first install, and this is not a security
hole, that does not seem important, so either asking in preinst of
shipping non-suid should work here.
The problematic situation seems to be upgrading to a different setup - you
change what is actually called in a given situation, and need to decide if
that's going to be suid or not, but because it is an upgrade, the user
might already be using it.
*This* case, IMO, clearly calls for a preinst.
Oh, another point. Don't be so sure that only the suid case can be a
security hole. Think about a setup where a different program simply does
not expect some binary to fail the way it does when not suid, and
interprets what it gets as success ... sure, that's a bug, but it can make
for a security hole anyway.
MfG Kai
Reply to: