Re: dpkg-statoverride vs. suidmanager
On Wed, Nov 29, 2000 at 03:57:47PM -0800, Joey Hess wrote:
> Ben Collins wrote:
> > On Wed, Nov 29, 2000 at 06:06:22PM -0500, Matt Zimmerman wrote:
> > > Now that we have dpkg-statoverride, how should setuid binaries be handled?
> > > Should new packages continue to use suidmanager? Should the binaries be
> > > shipped setuid, giving the user the option to use a statoverride?
> >
> > Ship them with the default that suits the binary, and allow users to
> > override that. Usually, now that we have statoverride, it is ok to ship
> > suid, but that's particular to the program.
>
> I think there are still questions about how to transition a package from
> suidregistered binaries to statoverridden binaries. After all, you don't
> want whatever the user did with suidregister to be forgotten when they
> upgrade..
>
i have an idea but i still have to start reading this thread, so this could
be completely off-topic.
what is a new release of suidmanager worked with/on statoverrides? every new
package that needs to work with setuid et al could start directly with
statoverrides, the old still would work with suidregister but this time
leaving a coherent state in the statoverrides database since suidmanager
now works with that database (i'm nearly not knowing anything of this topic
but suidmanager suite).
> If anyone figures this out, debhelper will start magically using
> statoverride instead of suidregister for everything.
>
the solution i propose doesn't solve the matter with debhelper
-----[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
--[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Reply to: