TorizonCore-Builder produces unremovable output as root during provisioning

Technical Support
, , , , ,
1

I have configured our CI system to add provisioning data to the image as part of the build process.

However, the output_provisioned directory is created as owned by root and with permissions that prevent it being removed by anyone but root.

[Update checkout directory ([path])] /usr/bin/git clean -f -d -X
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/LA_OPT_NXP_SW.html: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/image.json: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/toradexlinux.png: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/marketing.tar: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/u-boot-initial-env-sd: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/torizon-core-docker-verdin-imx8mp.ota.tar.zst: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/wrapup.sh: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/imx-boot: Permission denied
[15:00:49]	[Update checkout directory ([path])] warning: failed to remove output_provisioned/prepare.sh: Permission denied

This causes subsequent builds or non-root processes that expect to remove this folder to fail.

How can this be addressed without granting excessive permissions to the build agent process?

2

Greetings @bw908,

With TorizonCore Builder there is a certain behavior for setting the ownership of files and directories that get generated. Simply it copies the UID/GID of the current working directory used by TorizonCore Builder and uses that to set the UID/GID of all files and directories generated.

If output_provisioned is root owned then that must mean the working directory was root owned as well. Therefore you need the working directory to have the UID/GID you want output_provisioned to have. Though I don’t know how trivial or complex this is for your CI system.

Best Regards,
Jeremias

3

I still think there is a first-use bug somewhere as the working directory is owned by the user “tcagent” as are all its contents, and this is the user the service runs as. The issue is unrelated to CI as the same thing happened in a different checkout. However, after removing the folder(s) and repeating the build the problem does not seem to recur.

4

However, after removing the folder(s) and repeating the build the problem does not seem to recur.

That sounds very strange. Could you see if you could find a reproducible way to make this behavior happen. That way we can analyze if there really is a first-use bug of some kind.

Best Regards,
Jeremias

5

Yes, I will try to make it recur in the next day or so when I am working in that area again .

6

@jeremias.tx

I think I foundthe problem and it’s cleanup related. These folders generated during the build are all created and owned by root during the process, but it looks like they are chmodded as a last step before the process completes. So if something interrupts or causes the tcb command to abort, you will be left with these uncleanable directories.

You can easily reproduce this e.g. with the ‘bundle’ command and then press CTRL-C before it completes - the specified output directory and its contents will remain owned by root with 644 permissions (rw-r–r–)

7

So was a TorizonCore Builder process being interrupted during your CI?

You can easily reproduce this e.g. with the ‘bundle’ command and then press CTRL-C before it completes

This behavior is known due to how TorizonCore Builder only changes ownership of generated files at the end of a process.

Best Regards,
Jeremias

8

I don’t think it was interrupted, rather it encountered an error of some kind - but the end result was the same.

9

I’ll see if I can put in a request to our team to try and improve this behavior.

1 Like
10

Thanks, that would be helpful!

11

I’ve went ahead and made the request for our team. If there’s any action taken on this I’ll try to notify you.

Best Regards,
Jeremias

1 Like