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

Re: problems with latest x version in incoming



"Adam J. Klein" <aklein@eskimo.com> writes:

> On Thu, Oct 22, 1998 at 12:35:52AM -0700, Joey Hess wrote:
> > Adam J. Klein wrote:
> > > This is rather strange.  I took over this package relatively recently.  I
> > > hadn't really looked at the documentation.
> > 
> > Do you have time to fully look at how suidmanager works and find out if and
> > why the chown is necessary if suidregister doesn't run?
> 
> It looks like it's not neccessary.  I'm not sure what the original
> intention was, but it should be safe to change debhelper and debstd to
> inserting only:
> 
> if [-x /usr/sbin/suidregister ]; then
> 	suidregister -s PACKAGE FILE OWNER GROUP PERMS
> fi
> 
> in the postinst.  I'll fix the documentation in the next release.  I'm planning
> to rewrite suidmanager in Perl, which I hope will give me a better understanding
> of it's exact behavior, and make it easier to add features.

It most certainly _is_ necessary!

As many people have pointed out, doing it this way (that is, ship the
binary suid root in the package) as opposed to shipping the binary in
the package not suid root and doing a chmod means that there is a
window between the time when a package is unpacked and the time it is
configured during which there's an suid root binary sitting out there
that isn't being managed by suidregister.

And this window is not small.  For example, if I use dpkg -i to
manually install some package, yet forget to install one of the
packages it Depends: on, the package will be unpacked but not
configured.  It will remain in that state until I hunt down everything 
it Depends: on, install them, and do a dpkg --pending --configure.


Reply to: