Re: Packages' use of dpkg-statoverride
On Wed, Jan 10, 2001 at 03:58:38PM -0800, Joey Hess wrote:
> Anthony Towns wrote:
> > Eh? Surely you should be asking in the package's preinst?
> >
> > Ideally, IMHO, there should be a pre-depends on debconf, a debconf question
> > about the permissions, the package should be distributed with the binary
> > setuid (?), and if the user's said they want the permissions different to
> > the default, dpkg-statoverride should be called in preinst.
> >
> > Actually, there's no *need* to distribute it setuid in this case. I can't
> > think of any particularly compelling reason to do it either way.
>
> It would be simplest and cleanest to not distribute it suid, to prompt in the
> config script about whether the admin wants it suid, and to conditionally
> make it suid and statoverride it in the postinst. This has no unwwanted-suid
> windows, no nasty predependancies, and no modification of the filesystem in
> the config script.
What if the user has already configured a statoverride for the program, before
even installing the package (or using an earlier version, etc.)? Should the
config script even ask the question, or skip it?
Currently, I am planning to do this (for pchar):
- Ship non-setuid
- In config: ask whether pchar should be installed setuid, with a note:
If you already have a statoverride for /usr/sbin/pchar, your configuration
will be left alone (your answer here doesn't matter).
- In postinst: if there is a statoverride already in place, do nothing.
Otherwise, if the user answered yes, add a statoverride.
Since the answer to the question is ignored if there is a statoverride in
place, should I even bother asking it?
Also, should the statoverride be removed when the package is purged (as far as
I know, dpkg doesn't try to do this)?
--
- mdz
Reply to: