> > 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 title. > 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. -Brandon
Attachment:
signature.asc
Description: PGP signature