Mail archive

Re: [alpine-aports] main/busybox: split package into core and suid subpackages

From: Natanael Copa <>
Date: Thu, 22 Oct 2015 18:11:11 +0200

On Sat, 17 Oct 2015 16:46:57 +0200
Christian Kampka <> wrote:

> Hi,
> since this patch probably needs some explanation, I'd like to give an
> explanation to why I'd like to see this accepted. The current
> structure of the busybox packages, which includes the bbsuid binary
> as well as busybox forces every alpine installation to include the
> suid binary to provide functionalities like mount, passwd or su. If
> alpine is run as a chroot or docker container or likewise
> installation , which is no longer uncommon these days, having suid
> binaries included in installation should no longer be required and is
> imo quite undesirable if you think about security.

Makes perfect sense.

> The proposed patch splits the busybox package into two subpackages,
> busybox-core and busybox-suid. The core package contains everything
> that is currently included in the busybox package except for the
> bbsuid binary. This will be shipped via the busybox-suid package. The
> busybox package will be turned into a metapackage that pulls in
> busybox-core and busybox-suid, so for most use cases nothing will
> change except for those installations that desire it explicitly.

I wonder if we somehow can solve this with totally 2 packages:
  busybox + busybox-suid
instead of totally 3:
  busybox-core + busybox-suid + busybox.

We could for example add busybox-suid as a dependency to alpine-base,
or assume that busybox-suid is needed if some other package like openrc
is installed and have install_if="busybox=$pkgver openrc". I wonder
what happens then, if you "apk add !busybox-suid" to opt out?

I suppose the most critical thing we want avoid is someone end up
locked out from remote box due to 'su' not working after an upgrade.

> I am aware that alot of packages currently depend on the busybox
> package. I think it would be feasable enough to update those step by
> step to required only the subpackages they really need to depend on
> (which probably is not or should not be suid in most cases).
> I'm looking forward to your thoughts.

> Cheers,
> Christian
> ---
> Unsubscribe:
> Help:
> ---

Received on Thu Oct 22 2015 - 18:11:11 UTC