Bug#568313: Suggestion: forbid the use of dpkg-statoverride in postinst scripts, except for --list
Brandon <winterknight@nerdshack.com> writes:
> I still think that dpkg-statoverride should be forbidden in the case
> where the uid and gid are static.
Policy basically already does that, doesn't it? It's not normative (maybe
it should be), but that's how I always read 10.9.1:
Given the above, dpkg-statoverride is essentially a tool for system
administrators and would not normally be needed in the maintainer
scripts. There is one type of situation, though, where calls to
dpkg-statoverride would be needed in the maintainer scripts, and that
involves packages which use dynamically allocated user or group ids.
That's a fair bit short of forbidden in strength, but that's the general
gist of it.
I'd personally be happy to strengthen that to say that you should only use
dpkg-statoverride in maintainer scripts if you're handling dynamic UID/GID
file ownership. I don't see any immediate downside to doing so; other
changes should be handled directly by the permissions set in the *.deb.
> I still don't like the idea of using statoverride for the case where uid
> or gid are dynamic, though. If the owner and permissions in the package
> binary were set to sane defaults, then that would alleviate security
> concerns for that window, but the permissions would still be wrong. I
> don't know of another way around that. Using dpkg-statoverride in
> postinst is a messy solution, but the only one I can think of that keeps
> the permissions correct during that window when the uid or gid are
> dynamic.
Thankfully, this is a relatively rare case, since normally binaries don't
need to be owned by dynamic UIDs or GIDs. It's mostly limited to a small
handful of special setuid or setgid situations.
On my local system, for instance, I have:
windlord:~> dpkg-statoverride --list
root postdrop 2555 /usr/sbin/postdrop
root postdrop 2555 /usr/sbin/postqueue
root mlocate 2755 /usr/bin/mlocate
postfix postdrop 2710 /var/spool/postfix/public
root ssl-cert 710 /etc/ssl/private
root video 2755 /usr/lib/w3m/w3mimgdisplay
which is not horribly long. (And that last one looks incorrect to me on
first glance, but I may be missing some subtlety.)
In retrospect, I suspect we would have been better off if ssl-cert were a
statically-allocated group, but oh well.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: