X-Original-To: alpine-aports@mail.alpinelinux.org Delivered-To: alpine-aports@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id CEFB0DC1184 for ; Mon, 26 Oct 2015 08:36:30 +0000 (UTC) Received: from newmail.tetrasec.net (unknown [74.117.189.116]) by mail.alpinelinux.org (Postfix) with ESMTP id A82DDDC010F for ; Mon, 26 Oct 2015 08:36:30 +0000 (UTC) Received: from ncopa-desktop.alpinelinux.org (unknown [79.160.13.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by newmail.tetrasec.net (Postfix) with ESMTPSA id 748F35A82DA; Mon, 26 Oct 2015 08:25:59 +0000 (GMT) Date: Mon, 26 Oct 2015 09:36:25 +0100 From: Natanael Copa To: Christian Kampka Cc: alpine-aports@lists.alpinelinux.org Subject: Re: [alpine-aports] main/busybox: split package into core and suid subpackages Message-ID: <20151026093625.1c1f54bb@ncopa-desktop.alpinelinux.org> In-Reply-To: References: <1445093218-3450-1-git-send-email-christian@kampka.net> <20151022181111.5a0f7369@ncopa-laptop> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-alpine-linux-musl) X-Mailinglist: alpine-aports Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP On Thu, 22 Oct 2015 18:39:30 +0000 Christian Kampka wrote: > > > > > 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. > > > > I did not go for this option because it introduces a breaking change, but > it is certainly desirable in the long run. Since 3.3 is now in freeze, it > may be OK to possibly break dependencies here. > > > > > 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? > > > > Having busybox-suid as a dependency to alpine-base is crucial, If we can let alpine-base depend on busybox-suid then I think we will be fine and can probably just drop the busybox-core package. > but I think > we need to take care of packages that really require it, eg. mkinitfs > without suid could lead to really interesting problems. How? the suid binaries are only: "/bin/mount", "/bin/ping", "/bin/ping6", "/bin/umount", "/usr/bin/crontab", "/usr/bin/passwd", "/usr/bin/su", "/usr/bin/traceroute", mkinitfs needs to run as root already so it should not need elevate any privileges and thus should not need anything suid root. I think the only things that may need suid are things like ping/ping6 (any scripts using ping?) and interactive use like su and passwd. I don't think it is simple to find out what packages that actually needs suid. Even postgresql init.d script uses su but I expect su work without suid in that case because it will reduce permissions from root to user 'postgres'. > Having a metapackage for the transition would soften the blow. > I don't have the overview yet to really offer a qualified opinion > here. What I'd like to do is avoid the busbyox-core vs busybox package. If we introduce the busybox-core package and other packages start depend on it, then we will have problems getting rid of it in future. > > 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. > > > > Yes, definitely. > Let me know what you decide is the best way to proceed, I'll make the > necessary modifications to the patch. > Thanks for reviewing this. I think, split bbsuid to separate package and adding it as a dependency to alpine-base should work. Or am I missing something? > Cheers, > Christian --- Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org Help: alpine-aports+help@lists.alpinelinux.org ---