Permission errors with a distro package inside of Docker containers

[jeanas]

Hi,

I'm not quite sure how to phrase the title of this question... The issue is a mystery for me. I'm quite new to GitHub actions, so keep in mind that it could be something simple, but I am obviously missing something.

For context, here is the upstream discussion in the LilyPond project:

https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00062.html
https://gitlab.com/lilypond/lilypond/-/issues/6460

LilyPond is a text-based music score compiler (“LaTeX for music scores”). In short, the issue is that when trying to use LilyPond in GitHub actions, it fails if (1) the job runs in a Docker container (with container: {image: ...}) and (2) LilyPond is installed from the Linux distro, be it Ubuntu or Fedora. However, it does not reproduce if container: ... is not used. Also, it does not reproduce when using the shell to download, unpack and run the official LilyPond generic Linux packages.

The error thrown by LilyPond is

warning: g_spawn_sync failed (0): gs: Failed to close file descriptor for child process (Operation not permitted)
fatal error: cannot rename `document-tmp-2786319.384671.pdf' to `document.pdf'

The operation that leads to the last fatal error is a simple call to the C standard library rename () function, which returns a nonzero status code.

In other words, it looks like the LilyPond process does not have the necessary permissions on the file system.

There is a reproducer here:

https://github.com/Witiko/lilypond-github-actions-example

This is the action definition (there is also a small document.ly LilyPond file):

name: Typeset document
on:
  push:
  pull_request:
  workflow_dispatch:
env:
  DEBIAN_FRONTEND: noninteractive
jobs:
  typeset-document:
    name: Typeset document
    runs-on: ubuntu-latest
    container:
      image: ubuntu:latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Install Lilypond
        run: |
          set -e
          apt-get -qy update
          apt-get -qy install --no-install-recommends lilypond
      - name: Typeset score
        run: lilypond document.ly

In my fork at https://github.com/Jean-Abou-Samra/lilypond-github-actions-example, you can find an action definition that shows that it doesn't work with Fedora 37 either, and that it does work with official, standalone LilyPond binaries.

This issue also seems not to be reproductible in Docker containers outside of GitHub actions.

Given that it doesn't work neither with the Ubuntu package, nor with the Fedora package (the latter of which I am using myself), it must be something generic, but what? What can make a difference of permissions between the distro packages and the standalone binaries on two different systems inside GitHub actions? I am pretty puzzled. Any clue?

Thanks in advance.

[david-engelmann]

You can pass the following options to make the container run as root so the necessary permissions are used

runs-on: ubuntu-latest
container:
  image: ubuntu:22.04
  options: --user root

[jeanas]

Thanks for the tip, but I just tried it and it gives the same error (https://github.com/Jean-Abou-Samra/lilypond-github-actions-example/actions/runs/3414247199/jobs/5681948203).

[airtower-luna]

Actions does a whole lot of mounting and overriding environment variables (including HOME) when starting a job container. I don't have an obvious one that'd break things for you, but that's where I'd start looking, because it's specific to Actions and using a job container.

Example from one of your logs: https://github.com/Jean-Abou-Samra/lilypond-github-actions-example/actions/runs/3413390980/jobs/5680044999#step:3:27

[david-engelmann]

You nailed it, the full path was not being referenced in the final commands

[jeanas]

Actions does a whole lot of mounting and overriding environment variables (including HOME) when starting a job container. I don't have an obvious one that'd break things for you, but that's where I'd start looking, because it's specific to Actions and using a job container.

Thanks, I'll look at this tomorrow.

You nailed it, the full path was not being referenced in the final commands

As said below, that was intentional and meant to demonstrate the problem.

[david-engelmann]

I was able to fix the intentional problem, check out my last reply or my Pull Request in your sample repo

[david-engelmann]

I was able to get the build to run successful in this job. Basically, you were not refencing the newly installed instance of lilypond. the important lines are as follows

sh lilypond-2.22.2-1.linux-64.sh --prefix $(pwd)/official-binaries
official-binaries/bin/lilypond document.ly
official-binaries/bin/lilypond document.ly

The first line states install this in the official-binaries folder, so the second line should use the binaries built there!

[jeanas]

Ummm... The point of this example was exactly to show that the problem only arises with the distro package.

# You can see in the logs that this succeeds
official-binaries/bin/lilypond document.ly
# Whereas this fails, which is exactly the problem
lilypond document.ly

[david-engelmann]

My bad, I added a whereis lilypond, the results of that should be added to the PATH variable. Check out this write up on it. I had to step away from my computer but I can PR it into your repo when I'm back

[david-engelmann]

I was able to fix the issue by adding the following option --security-opt seccomp=unconfined, I submitted the changes as a pull request to your example repo. Please let me know if there is anything else I can do to help!

[jeanas]

Thanks, this seems to work! I'm not sure what exactly LilyPond does in its way of invoking GhostScript that is prevented by the seccomp sandbox, but I for one am happy with the workaround (I hope the original person who needed this will be too).

[Witiko]

Very happy. I am already using the workaround in https://github.com/Witiko/high-level-languages-for-tex. Thank you both.

[david-engelmann]

9.1