/etc/profile.d/debuginfd.{sh,csh} are created with 600 permissions

[Russell Greene]

[ Impact ]

Users installing libdebuginfod-common (the package that ships the shell snippets responsible for configuring the DEBUGINFOD_URLS environment variable, which will ultimately be used by GDB to contact the Ubuntu debuginfod service) experience a problem caused by permissions being set too tightly for /etc/profile.d/debuginfod.{sh,csh}. This results in DEBUGINFOD_URLS not being set for non-root users.

[ Test Plan ]

Inside a Jammy container:

# apt install -y libdebuginfod-common
# ls -lah /etc/profile.d/debuginfod*

Verify that the permission of both files allow them to be world-readable.

[ Where problems could occur ]

Care has been taken to not modify existing file permissions unnecessarily by using "g+r,o+r" when invoking chmod, but it is still possible to conceive a scenario where upgrading the package would make the files world-readable when the user is actually expecting otherwise. However, such "regression" would arguably not be something supported because if the intention is to prevent non-root users from making use of debuginfod, there are better ways to achieve it.

[ Original Description ]

In a fresh container, installing libdebuginfod-common gives a /etc/profile.d that looks like this:

```
root@32f34f7e271e:/etc/profile.d# ls -lah
total 24K
drwxr-xr-x 1 root root 4.0K May 26 17:23 .
drwxr-xr-x 1 root root 4.0K May 26 17:23 ..
-rw-r--r-- 1 root root 96 Oct 15 2021 01-locale-fix.sh
-rw------- 1 root root 677 May 26 17:23 debuginfod.csh
-rw------- 1 root root 692 May 26 17:23 debuginfod.sh

```

when I login as a nonprivledged user, DEBUGINFOD_URLS is not set because the permissions are incorrect on the profile files.

```
# dpkg -l | grep libdebug
ii libdebuginfod-common 0.186-1build1 all configuration to enable the Debian debug info server
```

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robie Basak (racb)]

> This results in DEBUGINFOD_URLS not being set for non-root users.

Should the Test Plan not then check that DEBUGINFOD_URLS is actually set correctly, and that debuginfod functionality actually works?

[Sergio Durigan Junior (sergiodj)]

You're correct, but your message made me look a bit deeper into the issue and made me remember that, for Jammy, installing libdebuginfod-common alone won't configure the system to use our debuginfod service.

I would like to turn this bug into a broader "make sure we enable support for debuginfod.ubuntu.com when installing libdebuginfod-common" thing. WDYT (as an SRU team member)?

[Robie Basak (racb)]

I discussed this with Sergio elsewhere and we concluded that we don't want to change behaviour in Jammy to opt users in to start automatically reaching debuginfod.ubuntu.com without further discussion. So for this bug, we'll consider the issue to be simply that if the user configures a server in /etc/debuginfod/, then the installed profile snippets won't pick it up so that won't work. Sergio will update the User Impact, Test Plan etc and then we'll be able to fix and validate this on that basis.

Changing behaviour in Jammy by opting users in to debuginfod.ubuntu.com by default would then be a separate discussion and (if necessary) tracked in a separate bug.

[Andreas Hasenack (ahasenack)]

An upload of elfutils to jammy-proposed has been rejected from the upload queue for the following reason: "Requested by sergiodj on IRC and "in person" in a google meet.".