Broken filesystem permissions on Ubuntu runners (/usr/share/aclocal)

[NWilson]

Description

When running on the Ubuntu runners (22.04 and 24.04) the filesystem permissions in certain directories are set to ugo+rwx.

This is very strange: it's an Ubuntu VM, and these files are installed by apt (as far as I can tell), and yet they are executable and world-writable. I have no idea what the cause is.

Impact

We use the libtool build tool, which copies files from /usr/share/aclocal into the build directory and then creates a tarball containing the copied files. Therefore, the permissions set on files in /usr/share/aclocal become copied into the release artifacts (the tarball contains file permissions).

The permissions on files in /usr/share/aclocal actually matter.

Detailed permissions

Inside a GitHub actions runner:

Run ls -l /usr/share/aclocal
total 484
-rwxrwxrwx 1 root root   1939 Mar 23  2022 bison-i18n.m4
-rwxrwxrwx 1 root root   1442 Mar  4  2022 expat.m4
-rwxrwxrwx 1 root root   8371 Sep 21  2022 glib-2.0.m4
-rwxrwxrwx 1 root root  15744 Sep 21  2022 glib-gettext.m4
-rwxrwxrwx 1 root root   8171 Jan 18  2022 gpg-error.m4
-rwxrwxrwx 1 root root   4085 Jan 18  2022 gpgrt.m4
-rwxrwxrwx 1 root root   3589 Sep 21  2022 gsettings.m4
-rwxrwxrwx 1 root root   5091 Dec  6  2021 gsl.m4
-rwxrwxrwx 1 root root   6242 Mar 24  2022 libgcrypt.m4
-rwxrwxrwx 1 root root 306681 Mar 24  2022 libtool.m4
...

Inside an ordinary (non-GitHub) default installation of Ubuntu:

ls -l /usr/share/aclocal
total 392
-rw-r--r-- 1 root root   1465 Feb  5  2024 cmake.m4
-rw-r--r-- 1 root root   1442 Feb 29  2024 expat.m4
-rw-r--r-- 1 root root 308138 Apr  8  2024 libtool.m4
-rw-r--r-- 1 root root   7905 Mar 31  2024 libxml2.m4
-rw-r--r-- 1 root root   2670 Apr  8  2024 ltargz.m4
-rw-r--r-- 1 root root  30078 Apr  8  2024 ltdl.m4
-rw-r--r-- 1 root root  14525 Apr  8  2024 ltoptions.m4
-rw-r--r-- 1 root root   4395 Apr  8  2024 ltsugar.m4
-rw-r--r-- 1 root root    714 Apr  8  2024 ltversion.m4
...

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

  Image: ubuntu-24.04
  Version: 2024120[8](https://github.com/PCRE2Project/pcre2/actions/runs/12369753741/job/34522317071?pr=630#step:1:9).1.0
  Included Software: https://github.com/actions/runner-images/blob/ubuntu24/20241208.1/images/ubuntu/Ubuntu2404-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20241208.1

  Image: ubuntu-22.04
  Version: 20241211.1.0
  Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20241211.1/images/ubuntu/Ubuntu2204-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20241211.1

Is it regression?

No

Expected behavior

I expect the files in /usr/share/aclocal to have permissions u+rw, go+r.

Actual behavior

Instead, the files have permissions ugo+rwx.

Repro steps

Here is a link to a test job:
https://github.com/PCRE2Project/pcre2/actions/runs/12369753741/job/34522316597?pr=630

Here is my Workflow YAML. When this workflow is run, the permissions are clearly wrong (compared to a standard Ubuntu installation), and this messes up the build artifacts for workflows which use libtool.

name: Build
on:
  workflow_dispatch:
  push:
    branches: [ master, "release/**" ]
  pull_request:
    branches: [ master ]

permissions:
  contents: read

jobs:
  test22_04:
    runs-on: ubuntu-22.04
    steps:
      - name: Testing
        run: |
          ls -l /usr/share/aclocal

  test24_04:
    runs-on: ubuntu-24.04
    steps:
      - name: Testing
        run: |
          ls -l /usr/share/aclocal

[vidyasagarnimmagaddi]

Hi @NWilson , Thank you for bringing this issue to our attention. We are looking into this issue and will update you on this issue after investigating.

[kishorekumar-anchala]

Hi @NWilson ,
We haven't made any changes to the file permissions for the default location/files. I kindly request that you correct the permissions in your workflow and try again.

Thank you!

[NWilson]

@kishorekumar-anchala I don't understand - I haven't made any changes to the file permissions. You can see my workflow YAML, which is a completely blank minimal test workflow: the file permissions are not correct in the GitHub VM.

[kishorekumar-anchala]

@NWilson -

Thank you for your message. We understand the importance of these permissions for your process, and we truly appreciate your transparency. However, as these permissions cannot be modified on our end, we kindly request you to update them according to your specific requirements. Thank you for your understanding!

[NWilson]

However, as these permissions cannot be modified on our end

But you have modified these permissions, somehow - you own and provide this Ubuntu VM image. It's your image which is providing official Ubuntu packages, but those packages (appear) to have been installed incorrectly.

The files in /usr/share/aclocal are in the image which is provided by GitHub Actions.

we kindly request you to update them according to your specific requirements

My "specific requirements" are: could you investigate why GitHub is providing official Ubuntu packages, with incorrect permissions?

[lanni-energinet]

@NWilson

This 3 year old commit is the cause.

https://github.com/actions/runner-images/blame/7c2da160a2b6077f8a1f7ae8833f71b0fbffc34b/images/ubuntu/scripts/build/configure-system.sh#L15

[kishorekumar-anchala]

The permission of the /usr/share directories were changed recursively, via this PR.
cc @NWilson

[NWilson]

You are making all the system files in the Ubuntu image world-writable and making them all executable? That is not an expected state for an Ubuntu installation.

I'm surprised that no-one's noticed for three years.

It looks like there were some scripts that were lacking the execute bit, and the original PR author just splatted that over the entire share directory, rather than fixing the specific files that needed it.

Many thanks for investigating this! I hope it's fixable.

[NWilson]

Wait, what? You've identified the bug, and now you're closing the ticket?

[kishorekumar-anchala]

Hi @NWilson , I mistakenly closed it, but I’ve reopened it now. thanks !