Permissions handled inconsistently between files: and write_files:, silently writing no file or a wrong file mode (yip-related))

[krumware]

elemental-toolkit version:

v2.3.2, with base image registry.suse.com/suse/sl-micro/6.2/baremetal-iso-image:2.3.0-7.111.

CPU architecture, OS, and Version:

x86_64, SUSE Linux Micro 6.2.

Describe the bug

The permissions field behaves differently depending on which of the two file-writing mechanisms you use, and the difference isn't documented.

write_files: (the cloud-init compatibility path) treats permissions as an octal string, so permissions: "0600" produces mode 0o600.

Extended files: (a yip stage step) treats permissions as a raw integer and applies it directly as the file mode (os.FileMode(n)). There, permissions: "0600" as a string doesn't unmarshal into the integer field and the file is silently not written. A bare permissions: 0600 depends on the parser: YAML reads it as octal 384 (correct), while a JSON/decimal path gives 600, which is mode 0o1130. Only the decimal 384 is unambiguous.

So the same permissions: "0600" works under write_files: but is silently dropped under files:. The docs show permissions: 0644 for files: without noting that it only works because YAML happens to parse the leading zero as octal.

To Reproduce

Consumed here through a Rancher SeedImage, whose spec.cloud-config is handed to yip on the node. Full object:

apiVersion: elemental.cattle.io/v1beta1
kind: SeedImage
metadata:
  name: perms-repro
  namespace: fleet-default
spec:
  type: iso
  baseImage: registry.suse.com/suse/sl-micro/6.2/baremetal-iso-image:2.3.0-7.111
  registrationRef:
    apiVersion: elemental.cattle.io/v1beta1
    kind: MachineRegistration
    name: <your-existing-machineregistration>
    namespace: fleet-default
  cloud-config:
    name: perms-repro
    stages:
      initramfs:
        - name: write a file via files with string permissions
          files:
            - path: /tmp/via-files.txt
              permissions: "0600"
              content: |
                hello

Boot a node from the resulting ISO. /tmp/via-files.txt does not exist, and nothing is logged about it. Change permissions: "0600" to permissions: 384 and it is created with mode 0o600.

For contrast, the same file written through write_files: (legacy cloud-config, replacing the cloud-config: block above) is created correctly at 0o600:

  cloud-config:
    write_files:
      - path: /tmp/via-writefiles.txt
        permissions: "0600"
        content: |
          hello

The same behavior reproduces without Rancher: place a yip config in a cloud-init dir and run elemental run-stage <stage>.

Expected behavior

files: and write_files: should handle permissions the same way (accept an octal string in both), or files: should error clearly when it receives a string or an out-of-range value instead of skipping the file silently. The docs should also state that files[].permissions is a numeric mode and give an unambiguous form (384 for 0o600, 420 for 0o644, 288 for 0o440).

Logs

• files: with permissions: "0600" writes no file and surfaces no error.
• A stored 600 gives ls -l mode 0o1130; NetworkManager then ignores the keyfile and nmcli con up <name> returns Error: unknown connection.
• Delivered via Rancher OS Manager 1.9; the cloud-config CRD field is schemaless (x-kubernetes-preserve-unknown-fields: true), so yip receives the value unchanged.

Additional context

Confirmed by testing: the CRD field is a schemaless passthrough, a stored 600 produces mode 0o1130, "0600" under files: produces no file, and "0600" under write_files: works. The exact yip unmarshaling path is inferred from these results rather than read from source.

Related:

• Inconsistent handling of stage file permissions in UI vs direct elemental#1780 is the companion issue, the same permissions handling as it surfaces through the Rancher UI, where 0600 is stored as decimal 600
• cloud-config complications elemental#1690 reports the general "cloud-config silently doesn't work" symptom this inconsistency can cause
• Enhance cloud-init syntax support #618 on broader cloud-init syntax support.

[krumware]

worth commenting that following the documentation was challenging for this.

• 1.9 nearest equivalent (uses permissions: 384, the safe form): https://documentation.suse.com/cloudnative/os-manager/1.9/en/operator-operational-tasks/declarative-networking/networking-static.html
• The actual broken example (permissions: 600) is 1.6-only: https://documentation.suse.com/cloudnative/os-manager/1.6/en/networking-vlans.html - but this doc is more easily discovered by folks in the cloud-config mode.

so 1.9 already quietly switched to 384, without, as far as I can see, documenting why 600 is now incorrect. It could be useful to call out permissions handling more specifically to help address this generally.