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

Re: Dropping debpkg from devscripts (in trixie)


On Mon, 2023-03-20 at 12:54:18 +0000, Benjamin Drung wrote:
> README for debpkg in devscripts says: "debpkg: A wrapper for dpkg used
> by debi to allow convenient testing of packages.  For debpkg to work, it
> needs to be made setuid root, and this needs to be performed by the
> sysadmin -- it is not installed as setuid root by default.  (Note that
> being able to run a setuid root debpkg is effectively the same as having
> root access to the system, so this should be done with caution.)  Having
> debpkg as a wrapper for dpkg can be a Good Thing (TM), as it decreases
> the potential for damage by accidental wrong use of commands in
> superuser mode (e.g., an inadvertent rm -rf * in the wrong directory is
> disastrous as many can attest to)."

Ugh, yes, this seems like very bad advice TBH. It also seems a bit
pointless? If you are going to open up such root back-door in your
system why all this complication, you might as well make dpkg itself
set-uid-root or set-gid-root (just to be clear, for unsuspecting
readers, the previous is not a recommendation; do not do that!).

And the wrapper is simply forwarding everything to dpkg itself, so
there is not much of filtering or sanitization going on there.

> The "Wrapper script" section in README from devscripts goes into the
> details and explains that you can invoke the wrappers with "sudo" or
> "super" or, highly dangerous, make debpkg setuid.

> debpkg uses a wrapper script written in C which makes devscripts
> architecture any. If we drop debpkg, we can make devscripts architecture
> all.

> IMO sudo (or equivalent) is superior to make debpkg setuid. Are there
> use cases that cannot be covered by using sudo? If there are no
> objections, my plan will be to remove debpkg from devscripts in trixie
> (i.e. after the bookworm release).

Yes, please, let's remove the wrapper and all the recommendations
about it. If there's a need/demand, I'd be happy to also include
a polkit action for dpkg itself (alongside the existing one for
update-alternatives), which could be an alternative to the
sudo/super usage.


Reply to: