Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fail if mountpoint path is forbidden by FCOS #240

Closed
rugk opened this issue May 16, 2021 · 6 comments · Fixed by #449
Closed

Fail if mountpoint path is forbidden by FCOS #240

rugk opened this issue May 16, 2021 · 6 comments · Fixed by #449
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers jira validation Issue related to config validation

Comments

@rugk
Copy link

rugk commented May 16, 2021

Bug

Operating System Version

fedora-coreos-34.20210503.1.1-live.x86_64 - current next stream

Ignition Version

2.9.0

Environment

bare-metal

Expected Behavior

Mounting succeeds.

Actual Behavior

The last line in the log of journalctl -t ignition, even after printing the whole Ignition config is:

}CRITICAL : Ignition failed: Mount path "/sysroot//mnt/external" contains non-directory component "/sysroot/mnt"

BTW yes the } at the start is really there, as it is the end of the Ignition config output it does there and in this case it seems to merge with that message…

This results in:

ignition-complete.target: Job ignition-complete.target/start failed with result 'dependency'.

Doing an ls on /sysroot/mnt, I can see this is somewhat correct as it's a symbolic link:

$ ls -la /sysroot/mnt
[…] /sysroot/mnt -> var/mnt

As you can see, it links to var/mnt (without a leading slash! – also wonder whether that's intended).

In any case, in my emergency dracut shell I at least also cannot see any /var/mnt directory…

Edit: Ah of course it's intended by rpm-ostree's file layout. However, in the link's target, i.e. /sysroot/var there is also only a lib folder, no other folder, i.e. no mnt it actually expects.

Reproduction Steps

variant: fcos
version: 1.3.0
storage:
  luks:
    # external disk (already exists!)
    - name: external
      label: luks-external
      device: /dev/disk/by-id/[…]:0-part1
      key_file:
        inline: |-
          ********
      wipe_volume: false
  filesystems:
    - path: /mnt/external
      device: /dev/mapper/external
      format: btrfs
      wipe_filesystem: false
      with_mount_unit: true

BTW the filesystems -> systemd service for mounting the file is filesystem is correctly generated.

Other Information

I continue my challenge to mount an existing LUKS drive from coreos/ignition#1210 (originally here)

FYI: When I then just reboot, it cannot even mount /root anymore, which is basically just configured as in the doc here (I did not include that part in the config above): It cannot find /dev/disk/by-label/root.

@bgilbert
Copy link
Contributor

On FCOS you can't create mountpoints directly in /; see docs here. If you set path to /var/mnt/external it should work, and will automatically create the mountpoint.

@rugk
Copy link
Author

rugk commented May 16, 2021

Oh thanks a lot! That works.

Given this seems to be a limitation of FCOS, do you think a pre-check in Butane could be implemented so this error is catched before when transpiling to an Ignition file?
(As the current error message that does not really pinpoint the actual problem at Ignition at the near end of provisioning is not too good – UX-wise.)

@bgilbert
Copy link
Contributor

Actually, yeah, that's a good idea.

@bgilbert bgilbert reopened this May 16, 2021
@bgilbert bgilbert changed the title Mounting fails, because of non-directory component “/sysroot/mnt” Fail if mountpoint path is forbidden by FCOS May 16, 2021
@bgilbert bgilbert transferred this issue from coreos/ignition May 16, 2021
@bgilbert bgilbert added enhancement New feature or request good first issue Good for newcomers labels May 16, 2021
@PhrozenByte
Copy link
Contributor

How about extending this to a more generalized path validation, i.e. not just limited to mount points? For example, Ignition will bail if a storage config for /usr is present, or if one tries to create a /some-file. Butane can (and should) deny this config from the beginning.

@jlebon
Copy link
Member

jlebon commented Mar 8, 2022

How about extending this to a more generalized path validation, i.e. not just limited to mount points? For example, Ignition will bail if a storage config for /usr is present, or if one tries to create a /some-file. Butane can (and should) deny this config from the beginning.

One thing with this is that Butane is also being used as input for CoreOS layering and there we do want to support changing things in /usr.

@aaradhak aaradhak self-assigned this Jul 12, 2022
@aaradhak aaradhak removed their assignment Jul 21, 2022
@bgilbert
Copy link
Contributor

bgilbert commented Aug 8, 2022

coreos/fedora-coreos-config#1879 aims to provide a way to create paths in the root directory. We might want to provide Butane sugar for that, but it doesn't completely obviate this issue, since there will still be forbidden paths (like /usr).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers jira validation Issue related to config validation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants