Image build fails on windows: Error while validating rootfs: entrypoint lacks execute permissions

[nachomata]

When executing corteca build on Windows with the build output set to rootfs, the command fails with the following error:

Error while validating rootfs: entrypoint lacks execute permissions: C:\Users\<user>\AppData\Local\Temp\<tmp dir>\rootfs\bin\<entrypoint>

This issue seems to be caused by this line, where the Docker output is set to type=local. On Windows, when using this output type, file permissions are lost because Windows and Unix handle file permissions differently.

As a result, the validation step fails when checking for the executable bit on the entrypoint inside the rootfs.

In version 31.1.0, I was able to work around this by changing the Docker output type to tar and then adjusting the way that the .tar.gz archive was created. However, in version 32.0.0, validation for the tarball was added, meaning additional changes are needed to fix it - modifying the validation to check permissions directly within the .tar file without extracting it.

The same error also occurs when using the --rootfs <rootfs.tar.gz path> option, because in this line, the tarball is extracted, again causing the loss of permissions.

Since switching from local to tar output is a significant change and may have broader implications, I'm opening this issue to discuss potential alternatives rather than submitting a (not fully tested) pull request right away.

---

Tar generated with version 32.0.0 on Linux (WSL):

test is the entrypoint. The image is generated successfully. (Local information like User and Group is present, not sure if this is desirable)

Tar generated with version 31.1.0 on windows (on version 32.0.0 it fails before generating it as explained)

test is the entrypoint. We can see that the permissions are lost. Additionally the symbolic links will not work because of the use of \ instead of /. This can be solved changing this line, but since the proposed solution is to directly generate the tarball with Docker, this issue will be fixed too.

Tar generated with version 31.1.0 on windows with the (not fully tested) quick fix:

test is the entrypoint. The permissions are preserved (and no local information like User is stored).

[aegagros]

Hi @nachomata

Thanks for your detailed feedback; really appreciate it.

I am guessing that you are currently trying under windows cli prompt or powershell right? I would assume that the above issues are not seen under WSL(v2).

Just to clarify, what I understand is that under windows when have docker output a folder structure, or when we manually extract a generated tarball, all execute file permissions are lost. This means that even if we override the validation failure, the final produced OCI image will fail to run, since the main entrypoint is not an executable (did you overcome this with 31.1.0?).

Your suggestion to have docker produce a tarball directly makes sense, but we need to make the subsequent operations (validation and annotation) work with either a tarball or a gzipped-tarball. Keep in mind that in 32.0.0 we added the option for the user to provide a custom-built rootfs in tar.gz format.

We were planning to allow more flexibility to provide this pre-built rootfs in either .tar, .tar.gz or even the root folder to a raw rootfs file layout, but obviously your findings put these plans into freeze status.

[nachomata]

Hi @aegagros

I am guessing that you are currently trying under windows cli prompt or powershell right? I would assume that the above issues are not seen under WSL(v2).

Exactly. Under WSL v2 (specifically using Debian), everything works fine. I've tested on Windows with PowerShell 7.5.0, Powershell 5.1.19041.5607 and CMD 10.0.19045.5608, and all produce the same issue.

Just to clarify, what I understand is that under windows when have docker output a folder structure, or when we manually extract a generated tarball, all execute file permissions are lost. This means that even if we override the validation failure, the final produced OCI image will fail to run, since the main entrypoint is not an executable (did you overcome this with 31.1.0?).

Yes, that's correct. The file permissions are lost and the test fails, but in version 31.1.0 the build was successful but the generated image did not have the correct permissions. Therefore when executing the image on the beacon, it fails with the error: lxc-start: test: start.c: start: 2121 Permission denied - Failed to exec "/bin/test"

Thank you for your support on this matter. If you need any additional information or further clarification, please let me know.

[tsopokis]

Hi @nachomata , this is a very interesting finding. I believe the only way to overcome this is to use a tarball as output and do the subsequent steps use the tarball created.

I think that you could have a workaround for this and change around line: https://github.com/nachomata/corteca-cli/blob/2e60cf41a797ee731d9baa257dd41aab1024c686/internal/fsutil/fsutil.go#L135 and if the OS is windows you can set (some?) files to 777 by using umask 0000.

[aegagros]

We are working on this from a different angle; the build step will be more transparent, with respect to the command sequence sent to docker, and the package step will be configurable with respect to the input type it will accept (tarball/folder layout)