public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Johannes Schauer Marin Rodrigues <josch@mister-muffin.de>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH] ldconfig: create /var/cache/ldconfig also with -r
Date: Wed, 12 Oct 2022 05:50:41 +0200	[thread overview]
Message-ID: <166554664124.1096741.9694830335625318209@localhost> (raw)
In-Reply-To: <Y0XZNZ4aPF2s6mWp@aurel32.net>

[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]

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 didn't
> > exist yet. With the -r option, a non-existing /var/cache/ldconfig inside
> > the chroot directory will *not* get created because chroot_canon() will
> > 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(-)
> > 
> > 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);
> >      }
> >  
> > -  const char *aux_cache_file = _PATH_LDCONFIG_AUX_CACHE;
> > -  if (opt_chroot != NULL)
> > -    aux_cache_file = chroot_canon (opt_chroot, aux_cache_file);
> > +  char *aux_cache_file = (char *)(_PATH_LDCONFIG_AUX_CACHE);
> > +  if (opt_chroot != NULL) {
> > +    aux_cache_file = alloca (strlen (opt_chroot) + strlen (_PATH_LDCONFIG_AUX_CACHE) + 2);
> > +    sprintf (aux_cache_file, "%s/%s", opt_chroot, _PATH_LDCONFIG_AUX_CACHE);
> > +  }
> 
> 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.

This code path (opt_chroot being NULL) is only reached if -r was specified and
the chroot() call didn't succeed. This happens, for example, when the user uses
fakeroot. So one can argue that:

 - 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 think they
   might be expected to keep the pieces

> To avoid changing the code too much, one way could be to call
> chroot_canon(opt_chroot, "/var/cache/ldconfig") and concatenate the result
> with "aux-cache".

Calling chroot_canon(opt_chroot, "/var/cache/ldconfig") will still return NULL
because /var/cache/ldconfig might not exist inside the -r directory. Doing so
would also ignore the setting of _PATH_LDCONFIG_AUX_CACHE.

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 NULL,
concatenate the paths manually instead?

Thanks!

cheers, josch

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmNGOY4ACgkQ8sulx4+9
g+EflQ//dNU9YOy04jhqCcNhsDG4F+mxhYwMZ1LLl7Hytz/JKRMlqkk3LD8UqC85
CxX02EeesgfZcJMdgzqvr28AsyRQsqCW/QJluzGiNYiRlJ44PKEJQaUgvAgoSKvA
rOv8344BX/4x8FV9T6vs1UfHNOmxVbcq7MsCEzKSv0oSQdipUL1Hw5fp03DvoAaK
mppw3T4drbT9gubB40crsDiwuMW2Mz/ebPOlJTKAcg1ebPF/VgYjukMycxx0EF1N
LuYjYTTqgKRcADUvcaVJWTXvQSsytjIK07ppx01zgjBFYvvDc0N8kEM2Yjux1368
LxqSGz4j6CmosAu+IqVt0DpfVd7mBr5+y/CaquZbbdCOBl9qdc+7VJ4TlJYXdbMm
Fqv3+RlocfsGMZu0vhQzradsYTtCXNWLKJsijxPIm8ybXzrJkY1KN8MKxF8jTCDy
9GY+fTSSA0J/wreZi5pGWJc1OZEdZJVZSDaNBs6ZWRXcwZp+jrtJ3gZ6rzOVGn5F
uCag33xjNSzzHu4YaGzGwu0M4KGXGHp6zSoqJvoC+oLK8mgne9I6t6nZUY+15nUt
qEx9+1JN6+E6XJpizaJxTubxs45gdaQfUg7G2JXdFMe8p3aPk/PtfxtFZIq8mj7m
6WwjOsdhL2xlxF7eql0gqxpHOv10ZbjldpPVaonCEEP9QlJrivU=
=KwAa
-----END PGP SIGNATURE-----

  reply	other threads:[~2022-10-12  3:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-11 12:20 Johannes Schauer Marin Rodrigues
2022-10-11 20:59 ` Aurelien Jarno
2022-10-12  3:50   ` Johannes Schauer Marin Rodrigues [this message]
2022-10-12 17:52     ` Aurelien Jarno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=166554664124.1096741.9694830335625318209@localhost \
    --to=josch@mister-muffin.de \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).