AlmaLinux9 Podman - SELinux is preventing /usr/bin/xmlstarlet from read access on the file gateway.xml_clean

I am having difficulty with SELinux blocking my Ignition 8.1.30 container from starting on AlmaLinux 9.2 running podman and podman-compose with a rootfull container.

In the Cockpit web gui under SELinux I see the following error message:

<EXPAND TO SEE ERROR MESSAGE>
SELinux is preventing /usr/bin/xmlstarlet from read access on the file gateway.xml_clean.

Solutions:
If you believe that xmlstarlet should be allowed read access on the gateway.xml_clean file by default.
You should report this as a bug. You can generate a local policy module to allow this access.
Unable to apply this solution automatically.
Allow this access for now by executing:
ausearch -c 'xmlstarlet' --raw | audit2allow -M my-xmlstarlet
semodule -X 300 -i my-xmlstarlet.pp

Audit log:
type=AVC msg=audit(1690466621.934:196): avc: denied { read } for pid=8446 comm="xmlstarlet" name="gateway.xml_clean" dev="dm-0" ino=203998497 scontext=system_u:system_r:container_t:s0:c174,c472 tcontext=system_u:object_r:container_file_t:s0:c505,c913 tclass=file permissive=0
type=SYSCALL msg=audit(1690466621.934:196): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55c20fc436d0 a2=0 a3=0 items=0 ppid=8445 pid=8446 auid=1000 uid=2003 gid=2003 euid=2003 suid=2003 fsuid=2003 egid=2003 sgid=2003 fsgid=2003 tty=(none) ses=1 comm="xmlstarlet" exe="/usr/bin/xmlstarlet" subj=system_u:system_r:container_t:s0:c174,c472 key=(null)

The interesting thing is I don't have any issues until I try to run the container for the 2nd time, after having deleted the previous container and started a new container using the same gw-data volume from the first instance (to allow upgrading the container and then restart to the same gateway data/config as before the upgrade).

The example below explains what I mean by this.

<EXPAND TO SEE EXAMPLE>
# printf supersecretpassword | podman secret create ignition_admin_password -
# podman-compose up -d
<Ignition is up and running with fresh install - no need to login to make any changes>
# podman-compose stop
<Ignition is stopped>
# podman-compose start
<Ignition starts again successfully>
# podman-compose down
<Ignition is stopped, container is deleted, but gw-data volume remains on disk so that next time we bring it up we kick off where we left off rather than a fresh install>
# podman-compose up -d
<SELinux error, container fails to start with error above>
# podman-compose down -v
<deletes volume from disk, wiping ignition so it will start next time with a fresh instance>
# podman-compose up -d
<working with fresh install>

I have not enable any additional security features or profiles - just the plain vanilla "server" install of AlmaLinux. This does come with SELinux on by default in enforcing mode, and I don't want to turn it off (I would like to find/fix the issue, rather than disable security protections).

Here is my podman-compose.yml file:

<EXPAND TO SEE PODMAN-COMPOSE.YML FILE>
# Docker Compose Example for inductiveautomation/ignition
# Compose Spec: https://github.com/compose-spec/compose-spec/blob/master/spec.md
---
services:
  # Ignition Gateway
  gateway:
    image: inductiveautomation/ignition:latest
    ports:
      - 8088:8088
      - 8043:8043
    volumes:
      - gw-data:/usr/local/bin/ignition/data
    # env_file: ignition.env  # optionally specify variables in a file, or using `environment:` below
    # --- THE BELOW LINES ARE ONLY REQUIRED WHEN STARTING A NEW GATEWAY FOR THE FIRST TIME ---
    environment:
      - ACCEPT_IGNITION_EULA=Y
      - GATEWAY_ADMIN_USERNAME=test
      - GATEWAY_ADMIN_PASSWORD_FILE=/run/secrets/ignition_admin_password
      - IGNITION_EDITION=standard
      - TZ=Australia/Perth  # see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
      - GATEWAY_MODULES_ENABLED=enterprise-administration,modbus-driver-v2,opc-ua,perspective,reporting,sql-bridge,symbol-factory,tag-historian,web-developer
      - DISABLE_QUICKSTART=true
    secrets:
      - ignition_admin_password
    command: >
      -n MyProject
      -m 1024
      --
      wrapper.java.initmemory=512
      -Dignition.allowunsignedmodules=true
 
secrets:
  ignition_admin_password:
    external: true

volumes:
  gw-data:

Anyone else seen this, or have any ideas how to fix it?

I'll take a look at this, but I don't have a matching environment built just yet.. I will say that we do use xmlstarlet in the entrypoint script to do the XML processing for gateway.xml (which contains the http/https/gan port configurations among some other things) prior to gateway launch.

Okay, I was able to spool this up today. The reason this is occurring is that the SELinux labels that are being applied to the volume (on the host side) are causing that different container (that you recreate and start up after a down+up) to run into access problems. Review this doc on mount-options for volumes on SELinux-enabled systems. Ultimately you probably just need to append :Z to your volume mount, e.g.:

...
    volumes:
      - gw-data:/usr/local/bin/ignition/data:Z
...
3 Likes

Thanks very much - this worked!

A bit embarrassing, because I'd been using the ":Z" in my previous attempts, and not sure why I dropped it off the end. Thanks for helping me identify this.

Do you think this could be captured somehow in the documentation here?

https://docs.inductiveautomation.com/display/DOC81/Docker+Image

Good idea, I’ll queue getting something for SELinux mentioned on there. :+1:

1 Like

Hi Kevin,

Happy new year to you.

Just checking in to see if this one is still in the queue?

I think a full SELinux write-up is out of scope here - just a sentence or two prompting the use of :Z if running on an SELinux system.