[Bug debuginfod/29022] New: 000-permissions files cause problems for backups

2022-04-04 Thread bugzilla at hadess dot net via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=29022

Bug ID: 29022
   Summary: 000-permissions files cause problems for backups
   Product: elfutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debuginfod
  Assignee: unassigned at sourceware dot org
  Reporter: bugzilla at hadess dot net
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

the debuginfod-client creates 000-permissions files as a way to mark "negative
caching". Unfortunately, that causes permissions problems for backup software,
disk usage checkers, etc. that rely on being able to access the user's own
files.

Given that the usage of those 000-permission files is not even atomic (see
commit 7d64173fb11c66284a408e52d41d15b7755d65d2), is there any reason not to
use the contents of the file, or the name of the file, or some other attribute
like the xattrs as a way to carry that "negative cache" information?

My backup software's log is hundreds of lines of:
Warning:
/home/hadess/.var/app/org.gnome.Totem.Devel/cache/debuginfod_client/d9ebf6de9e98f66a21daca59c8f601a9daa03c5b/debuginfo:
open: [Errno 13] Permission denied:
'/home/hadess/.var/app/org.gnome.Totem.Devel/cache/debuginfod_client/d9ebf6de9e98f66a21daca59c8f601a9daa03c5b/debuginfo'

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: patch: debuginfod ipv4-ipv6 dual-stack

2022-04-04 Thread Mark Wielaard
Hi Frank,

On Sun, 2022-04-03 at 19:49 -0400, Frank Ch. Eigler via Elfutils-devel wrote:
> commit 3a00f412b6554ba70f7b7e3d3aa6f67f278868af (HEAD -> master)
> Author: Frank Ch. Eigler 
> Date:   Sun Apr 3 19:42:48 2022 -0400
> 
> debuginfod: use single ipv4+ipv6 microhttpd daemon configuration
> 
> Use a single MHD_USE_DUAL_STACK mhd daemon.  This way, the thread
> connection pool is not doubled, saving memory and better matching user
> expectations.  A slight tweak to logging is required to pull IPv4
> remote addresses back out, and also to allow IPv6 ::-laden address
> forwarding through federation links.
> 
> Signed-off-by: Frank Ch. Eigler 
> 
> diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
> index 38a389e7dfd3..578d951d0102 100644
> --- a/debuginfod/ChangeLog
> +++ b/debuginfod/ChangeLog
> @@ -1,3 +1,12 @@
> +2022-04-03  Frank Ch. Eigler 
> +
> + * debuginfod.cxx (main): Use single dual-stack daemon setup,
> + rather than duplicate ipv4 and ipv6.
> + (conninfo, handle_buildid): Represent ipv4-mapped ipv6 addresses
> + in their native ipv4 form for logging and X-F-F: purposes.
> + * debuginfod-client.c (debuginfod_add_http_header): Tolerate
> + colons in http header values.

This looks ok. Some comments below, but nothing I think needs to
change.

>  2022-04-03  Frank Ch. Eigler 
>  
>   * debuginfod.cxx (main): Use MHD_USE_EPOLL for libmicrohttpd, to
> diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
> index 024b09545d99..41ba88a56911 100644
> --- a/debuginfod/debuginfod-client.c
> +++ b/debuginfod/debuginfod-client.c
> @@ -1548,13 +1548,13 @@ int debuginfod_find_source(debuginfod_client *client,
>  int debuginfod_add_http_header (debuginfod_client *client, const char* 
> header)
>  {
>/* Sanity check header value is of the form Header: Value.
> - It should contain exactly one colon that isn't the first or
> + It should contain at least one colon that isn't the first or
>   last character.  */
> -  char *colon = strchr (header, ':');
> -  if (colon == NULL
> -  || colon == header
> -  || *(colon + 1) == '\0'
> -  || strchr (colon + 1, ':') != NULL)
> +  char *colon = strchr (header, ':'); /* first colon */
> +  if (colon == NULL /* present */
> +  || colon == header /* not at beginning - i.e., have a header name */
> +  || *(colon + 1) == '\0') /* not at end - i.e., have a value */
> +/* NB: but it's okay for a value to contain other colons! */
>  return -EINVAL;

OK.

>struct curl_slist *temp = curl_slist_append (client->headers, header);
> diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
> index 99924d36f260..48e0f37b33f0 100644
> --- a/debuginfod/debuginfod.cxx
> +++ b/debuginfod/debuginfod.cxx
> @@ -1063,9 +1063,22 @@ conninfo (struct MHD_Connection * conn)
>  sts = getnameinfo (so, sizeof (struct sockaddr_in), hostname, sizeof 
> (hostname), servname,
> sizeof (servname), NI_NUMERICHOST | NI_NUMERICSERV);
>} else if (so && so->sa_family == AF_INET6) {
> -sts = getnameinfo (so, sizeof (struct sockaddr_in6), hostname, sizeof 
> (hostname),
> -   servname, sizeof (servname), NI_NUMERICHOST | 
> NI_NUMERICSERV);
> +struct sockaddr_in6* addr6 = (struct sockaddr_in6*) so;
> +if (IN6_IS_ADDR_V4MAPPED(&addr6->sin6_addr)) {
> +  struct sockaddr_in addr4;
> +  memset (&addr4, 0, sizeof(addr4));
> +  addr4.sin_family = AF_INET;
> +  addr4.sin_port = addr6->sin6_port;
> +  memcpy (&addr4.sin_addr.s_addr, addr6->sin6_addr.s6_addr+12, 
> sizeof(addr4.sin_addr.s_addr));
> +  sts = getnameinfo ((struct sockaddr*) &addr4, sizeof (addr4),
> + hostname, sizeof (hostname), servname, sizeof 
> (servname),
> + NI_NUMERICHOST | NI_NUMERICSERV);
> +} else {
> +  sts = getnameinfo (so, sizeof (struct sockaddr_in6), hostname, sizeof 
> (hostname), NULL, 0,
> + NI_NUMERICHOST);
> +}
>}

That IN6_IS_ADDR_V4MAPPED is funny. Is that actually used in practice?

>if (sts != 0) {
>  hostname[0] = servname[0] = '\0';
>}
> @@ -2008,13 +2021,26 @@ and will not query the upstream servers");
> 
> MHD_CONNECTION_INFO_CLIENT_ADDRESS);
>struct sockaddr *so = u ? u->client_addr : 0;
>char hostname[256] = ""; // RFC1035
> -  if (so && so->sa_family == AF_INET)
> +  if (so && so->sa_family == AF_INET) {
>  (void) getnameinfo (so, sizeof (struct sockaddr_in), hostname, 
> sizeof (hostname), NULL, 0,
>  NI_NUMERICHOST);
> -  else if (so && so->sa_family == AF_INET6)
> -(void) getnameinfo (so, sizeof (struct sockaddr_in6), hostname, 
> sizeof (hostname), NULL, 0,
> -NI_NUMERICHOST);
> -
> 

Re: patch: debuginfod ipv4-ipv6 dual-stack

2022-04-04 Thread Frank Ch. Eigler via Elfutils-devel
Hi -


> That IN6_IS_ADDR_V4MAPPED is funny. Is that actually used in practice?

Yeah, actually all the time.  On a dual-stack socket, an ipv4 connection
gets an ipv6 peer-address that renders like :::1.2.3.4.


> Too bad this cannot be merged with conninfo above.
> But this calculates less info.

Yeah.


> >obatched(clog) << "started http server on "
> > - << (d4 != NULL ? "IPv4 " : "")
> > - << (d6 != NULL ? "IPv6 " : "")
> > + << "IPv4 "
> > + << "IPv6 "
> >   << "port=" << http_port << endl;
> 
> This keeps the log output the same, but I wouldn't mind just removing
> the IPv4 and IPv6 strings.

Yeah, makes sense.  OK, will push with that change.


- FChE



[Bug debuginfod/29022] 000-permissions files cause problems for backups

2022-04-04 Thread fche at redhat dot com via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=29022

Frank Ch. Eigler  changed:

   What|Removed |Added

 CC||fche at redhat dot com

--- Comment #1 from Frank Ch. Eigler  ---
For what it's worth, these caches are all disposable, so you could exclude the
whole directory structure from backups or just delete it.

I'm not keen on a file-attribute solution, because it's less portable and it'd
still require SOME file to exist.  A 0-length file is not unambiguous (consider
empty source files).  A differently named file is a possibility.

(Pretty sure atomicity is an orthogonal consideration - TOCTOU is a possibility
with all the options.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/29022] 000-permissions files cause problems for backups

2022-04-04 Thread mark at klomp dot org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=29022

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #2 from Mark Wielaard  ---
Theoretically you can have a totally empty source files, but they are pretty
useless and they won't even leave any debug (DWARF) data (except for an empty
line table and compiler options string), so since there is no DWARF reference
to the source file it won't even be requested by any debuginfod consumer.
executables and debug files are ELF so are never zero size.

So I think it might make some sense to investigate whether we can use the fact
that a file is zero size as negative cache indicator. It would also get rid of
the "root is special" case.

At least I cannot imagine we really want to ever return a zero sized file. But
I might not have big enough imagination. There is always some theoretically
possibility that there is a legitimate request for a zero sized file in the
future. But do we really need to worry about that? Does it prevent some future
extensions?

-- 
You are receiving this mail because:
You are on the CC list for the bug.