From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hall.aurel32.net (hall.aurel32.net [IPv6:2001:bc8:30d7:100::1]) by sourceware.org (Postfix) with ESMTPS id CB1343858D38 for ; Wed, 12 Oct 2022 17:52:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB1343858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=aurel32.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=aurel32.net DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aurel32.net ; s=202004.hall; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Cc:From:Reply-To: Subject:Content-ID:Content-Description:X-Debbugs-Cc; bh=EpwmN+FwHoCUSuzmmVCK7wghP2xiXjYT4eJKCNAIs00=; b=g4JY4cnjhQlRQcsfdZYsk0ci0g vlvfC/wXoqN3rS+6sYJVTX1b1gQTSfBpLlEwOcpQTG/EnnsfBUhrBKXpU9bRgP3ZiuqYaqvDdbnTK 8optHq/ql3d7JmYHSsBF82QKryUyU0mUYI5gvhiy/NlFctgV3FRBjTsApxNtuyOWYhsUUgaR2CsPf VirBmFwDCPhnwJK8gw8XMk8u78DgI/P9T1N+D75S0Wnw5nnWVeC3H4liTM6i3hwbv1koqAr+cmvUx A5ZGrePi4+MuqOak3gztyhidYUSnppk4rd+QZ3S0ifMxmfm7sSCozS2oDnLOF+lKSkTnUTDOs/7OO EzCzk0qw==; Received: from [2a01:e34:ec5d:a741:8a4c:7c4e:dc4c:1787] (helo=ohm.rr44.fr) by hall.aurel32.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oifu1-004ySG-GT for libc-alpha@sourceware.org; Wed, 12 Oct 2022 19:52:21 +0200 Received: from aurel32 by ohm.rr44.fr with local (Exim 4.96) (envelope-from ) id 1oifu1-001r10-0Z for libc-alpha@sourceware.org; Wed, 12 Oct 2022 19:52:21 +0200 Date: Wed, 12 Oct 2022 19:52:21 +0200 From: Aurelien Jarno To: libc-alpha@sourceware.org Subject: Re: [PATCH] ldconfig: create /var/cache/ldconfig also with -r Message-ID: Mail-Followup-To: libc-alpha@sourceware.org References: <20221011122053.1005166-1-josch@mister-muffin.de> <166554664124.1096741.9694830335625318209@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WmUFjqebpQpXAhjq" Content-Disposition: inline In-Reply-To: <166554664124.1096741.9694830335625318209@localhost> User-Agent: Mutt/2.2.7 (2022-08-07) X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --WmUFjqebpQpXAhjq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-10-12 05:50, Johannes Schauer Marin Rodrigues wrote: > Quoting Aurelien Jarno (2022-10-11 22:59:33) > > On 2022-10-11 14:20, Johannes Schauer Marin Rodrigues wrote: > > > Without the -r option, ldconfig creates /var/cache/ldconfig if it did= n't > > > exist yet. With the -r option, a non-existing /var/cache/ldconfig ins= ide > > > the chroot directory will *not* get created because chroot_canon() wi= ll > > > return NULL if the path doesn't exist. This means that aux_cache_file > > > will be set to NULL and save_aux_cache() doesn't get executed at the > > > end. So instead of using chroot_canon() to prepending the chroot path, > > > combine the paths manually. > > > --- > > > elf/ldconfig.c | 8 +++++--- > > > 1 file changed, 5 insertions(+), 3 deletions(-) > > >=20 > > > diff --git a/elf/ldconfig.c b/elf/ldconfig.c > > > index e6c24e71a4..da76dc31b8 100644 > > > --- a/elf/ldconfig.c > > > +++ b/elf/ldconfig.c > > > @@ -1293,9 +1293,11 @@ main (int argc, char **argv) > > > add_system_dir (LIBDIR); > > > } > > > =20 > > > - const char *aux_cache_file =3D _PATH_LDCONFIG_AUX_CACHE; > > > - if (opt_chroot !=3D NULL) > > > - aux_cache_file =3D chroot_canon (opt_chroot, aux_cache_file); > > > + char *aux_cache_file =3D (char *)(_PATH_LDCONFIG_AUX_CACHE); > > > + if (opt_chroot !=3D NULL) { > > > + aux_cache_file =3D alloca (strlen (opt_chroot) + strlen (_PATH_L= DCONFIG_AUX_CACHE) + 2); > > > + sprintf (aux_cache_file, "%s/%s", opt_chroot, _PATH_LDCONFIG_AUX= _CACHE); > > > + } > >=20 > > This drops the use chroot_canon() call. I am afraid it might allows one > > to "escape" the "chroot". Imagine that /var/cache/ldconfig is a symlink > > pointing outside of the opt_chroot. >=20 > This code path (opt_chroot being NULL) is only reached if -r was specifie= d and > the chroot() call didn't succeed. This happens, for example, when the use= r uses > fakeroot. So one can argue that: >=20 > - escaping the "chroot" is not harmful because there were no sufficient > permissions to chroot() in the first place > - the user is running ldconfig in a non-default environment where I thin= k they > might be expected to keep the pieces I agree that the "security" implication are quite low with this option, but that is still a change from the existing behaviour. We should have the opinion of others to know if this is acceptable. > > To avoid changing the code too much, one way could be to call > > chroot_canon(opt_chroot, "/var/cache/ldconfig") and concatenate the res= ult > > with "aux-cache". >=20 > Calling chroot_canon(opt_chroot, "/var/cache/ldconfig") will still return= NULL > because /var/cache/ldconfig might not exist inside the -r directory. Doin= g so chroot_canon() allows the last element of the path to not exist. That is actually why it works when calling it with _PATH_LDCONFIG_AUX_CACHE where the aux-cache file does not exist. > would also ignore the setting of _PATH_LDCONFIG_AUX_CACHE. Yep, what I really meant was dirname(_PATH_LDCONFIG_AUX_CACHE), but i used the explicit path to avoid confusion. > Maybe what would be done to prevent the "escaping" was to first call the > original chroot_canon(opt_chroot, aux_cache_file) and, if the result is N= ULL, > concatenate the paths manually instead? That should limit the risk, but not totally. If /var/cache/ldconfig is a symlink pointing outside the chroot, chroot_canon() will return NULL. Concatenating the two paths will result in a path outside of the chroot. --=20 Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net --WmUFjqebpQpXAhjq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmNG/tUACgkQE4jA+Jno M2vxHg/8DGxQYXc7EMczcwVKyCOpVs6YgzLrC/SU8VuNJy4W5rY/UcjYzJ0mp+Wn BTf55f96Uyf8r4+OlcqsU96VBbU9pbCN7cbYVKmx2RYgHzffQpCeSAUpYUO+Rzdn hryxdyJqrHuuvSM/4Xkro388XDmrNn4AOnT6el9s/5ZuuFn5HQg2YlgEwIAGVEXi MeuGknyqyOdbdgHWSGTdugQSYT5FbGe8uw7+wnR4R/8ooTRohOd4Zb7k5FP6rwla gOUAulJFl3PXB0vnbYXPFHZ1RejiSUB9aLlpINrn064d3Q0v7AKc+AsJVXRG8Wg4 I8/Xbyh/8ZjWc7VrFXK3xfmAxQJfaONkdJf2a54pAAysOeFEw4BtiIZFJokJigEe yp6Mqu+X8eFUHJSRw9swA95sNVMBvFdbLO47nll+p4mVpcUSwW/OgryyCQOVUnV8 YbF+01+ExdOSRZKLsTS7vTI1ReAtl9kJch5Ou6+nI0yWp7JKxYDuzD8jcMIpTqrD 1fM3ae6t44r84sdGXPFaiOcdr8/nSOV2R3hOjuUtCybc3S/2rWYBWUt22va0hHge oK+IJY/DN4S8fG7tV2Bb68x92i8VfzFSKLY2IC7ckdZReqb8kNynojZkz4D23o/u sabAIOtZAktXwIo/psEr08BTVXuZ0MdqPSrOOH464BlBluOZQmk= =sW84 -----END PGP SIGNATURE----- --WmUFjqebpQpXAhjq--