Re: Capsicum and weak libc symbols

Sorry about the late answer. I've tried to get some time off to think
about the problem with my head clear.

I wanted to propose a process to decide which symbols should
deserve/warrant a weak symbol. Turns out I was unable to come up with
anything. Oldtime developers from the community should do that. I'm
not that old here.

So I'll just refactor my project to only support /lib/libc.so.7 and
fail when one is trying to build it against /usr/lib/libc.a.

Once there's a process to decide which symbols deserve a weak
definition on /usr/lib/libc.a, I can revisit my code.

Em qua., 26 de fev. de 2025 às 18:17, Konstantin Belousov
<kib@freebsd.org> escreveu:
> 1. How the situation with getaddrinfo() is different from that one for
>    opendir()/fdopendir()?

I only wanted to override opendir() (ambient authority), not
fdopendir(). If you have fdopendir(), you can trivially implement the
original opendir(). There's nothing similar in getaddrinfo() where I
could get access to the original implementation.

In Linux/glibc, I can access the "previous" getaddrinfo (even in
builds against /usr/lib/libc.a) through getaddrinfo_a():

  static int previous_getaddrinfo(
      const char *node, const char *service,
      const struct addrinfo *hints, struct addrinfo **res
  ) {
      struct gaicb cb;
      std::memset(&cb, 0, sizeof(struct gaicb));
      cb.ar_name = node;
      cb.ar_service = service;
      cb.ar_request = hints;
      cb.ar_result = NULL;
      struct gaicb* cbs = &cb;
      auto ret = getaddrinfo_a(GAI_WAIT, &cbs, 1, NULL);
      *res = cb.ar_result;
      return ret;
  };

> 2. Don't we end up with marking all libc symbols as weak if starting
>    the proposed route?

For my own use-cases, I only need to override symbols related to
ambient authority.

--
Vinícius dos Santos Oliveira