feat: simplify mounting as non-root

[hallyn]

If you are not root on the host, you can't mount with fs-verity. Atomfs currently makes you add the --allow-missing-verity flag to mount without verify. This means that non-host-root has to always specify that flag. That's silly, not helpful, and makes use in unprivileged lxc more painful.

Still spit out a warning, but don't refuse to mount if you are not host root.

[raharper]

If you are not root on the host, you can't mount with fs-verity. Atomfs currently makes you add the --allow-missing-verity flag to mount without verify. This means that non-host-root has to always specify that flag. That's silly, not helpful, and makes use in unprivileged lxc more painful.

Still spit out a warning, but don't refuse to mount if you are not host root.

Do we want a cli flag? Warnings aren't seen when used in scripts; but refusing without a flag would at least make script/caller look and update call sites.

[hallyn]

If you are not root on the host, you can't mount with fs-verity. Atomfs currently makes you add the --allow-missing-verity flag to mount without verify. This means that non-host-root has to always specify that flag. That's silly, not helpful, and makes use in unprivileged lxc more painful.
Still spit out a warning, but don't refuse to mount if you are not host root.

Do we want a cli flag? Warnings aren't seen when used in scripts; but refusing without a flag would at least make script/caller look and update call sites.

Well, we already have that, in the --allow-missing-verity option.

I was specifically looking to do lxc-create -t oci -n d1 -- --url oci:dir:squashfs-image. The lxc-oci template supports both atomfs and puzzlefs. But doesn't pass that argument. So to use this unprivileged, we have to update the template and the created container config (created by the template) to pass that argument - but only when using atomfs, and not when using puzzlefs, which so far are pleasantly common paths.

case "$mediatype" in
  application/vnd.*.image.layer.squashfs*)
    MOUNT_HELPER="atomfs"
    ;;
  application/vnd.puzzlefs.image.rootfs.*)
    MOUNT_HELPER="puzzlefs"
    ;;
esac
...
    "$MOUNT_HELPER" mount --persist "${MOUNT_HELPER_UPPERDIR}" "${OCI_DIR}:${OCI_NAME}" "$LXC_ROOTFS"
...
    echo "lxc.hook.pre-mount = $MOUNT_HELPER mount --persist ${MOUNT_HELPER_UPPERDIR}" \
        '${LXC_ROOTFS_PATH}/../oci:${LXC_NAME} ${LXC_ROOTFS_PATH}' \
        >> "${LXC_CONF_FILE}";;

[raharper]

If you are not root on the host, you can't mount with fs-verity. Atomfs currently makes you add the --allow-missing-verity flag to mount without verify. This means that non-host-root has to always specify that flag. That's silly, not helpful, and makes use in unprivileged lxc more painful.
Still spit out a warning, but don't refuse to mount if you are not host root.

Do we want a cli flag? Warnings aren't seen when used in scripts; but refusing without a flag would at least make script/caller look and update call sites.

Well, we already have that, in the --allow-missing-verity option.

I was specifically looking to do lxc-create -t oci -n d1 -- --url oci:dir:squashfs-image. The lxc-oci template supports both atomfs and puzzlefs. But doesn't pass that argument. So to use this unprivileged, we have to update the template and the created container config (created by the template) to pass that argument - but only when using atomfs, and not when using puzzlefs, which so far are pleasantly common paths.

While the path is clean, the behavior difference is stark, IIUC. Using a puzzlefs image will still verify the image, but an atomfs image won't get verified?

Given the goals of atomfs and puzzlefs providing image-integrity-at-runtime I do think diverging the codepath to raise error and allow user to override seems like the Right Thing (tm).

WDTY?