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

Bug#568313: Suggestion: forbid the use of dpkg-statoverride in postinst scripts, except for --list

> > First, I suggest that Debian Policy require, or at least recommend,
> > that packages not use dpkg-statoverride to set permissions for files
> > with static uids and gids. In other words, if it is possible for the
> > maintainer to set the permissions in the package binary itself, then
> > he should.
> What is the rationale for this?

The whole point of using dpkg-statoverride is to override maintainer
specified file permissions. There is no reason that a package
maintainer would need to "override" the permissions that they
specified. When a maintainer uses dpkg-statoverride, the permissions
are specified in the file attributes and in /var/lib/dpkg/statoverride,
but they only need to specified in one location.

It's ugly to have stuff that I did not specify in my statoverride list.

> What set of packages currently existing would be instantly buggy if
> this were the case?

I bet there will be several. On my system currently, xcdroast and
xsendmail use stat overrides unnecessarily.

> > As for setting permissions for files with dynamic ids, debian policy
> > says that dpkg-statoverride is necessary. This is not true, or at
> > least misleading. Certainly the post install script should check to
> > make sure that there isn't any override in place before setting file
> > permissions, but I think it would be better to set permissions with
> > chown and chmod than dpkg-statoverride.
> This is a bad idea. There's no advantage to using chown and chmod over
> dpkg-statoverride.

There are a few advantages. One, is that is less for the system to keep
track of. The statoverride file won't have so much cruft. Two, it is
actually easier for the maintainer. The only reason that any maintainer
would set overrides is because they don't know any better. chown/chmod
works just as well, it can usually be done in the rules file, so some
packages can get rid of their postinst, and you never have to undo it
in postrm (since the file gets removed on purge anyway).

Basically, dpkg-statoverride --add does more than chown/chmod, but
that extra stuff is unneeded cruft that needs to be ignored by the
adminstrator and eventually undone by the maintainer.

> In fact, you have to do more work,

No, less work. See above.

> because you have to check all of the things that dpkg-statoverride
> gets you for free, like making sure that dpkg-statoverride hasn't
> previously been set.

dpkg-statoverride --list <filename> makes sure that dpkg-statoverride
has not been set. And like I said, "except for --list". It's in the bug

> It also means that there will be a relatively long time when the
> package has been unpacked with the wrong permissions set until the
> postinst is called to fix them up.

That doesn't make any sense. In most cases, the permissions would be
set before they would with dpkg-statoverride, because you set it in the
rules file and it is included in the package binary. In the case that
you can't set it in the rules file, it would be set in the postinst
file at the exact same time that the maintainer would otherwise be
using dpkg-statoverride. In other words, there is no situation where
this would be true.


Attachment: signature.asc
Description: PGP signature

Reply to: