[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: