[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

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: