umask trouble when using archivedir

[tobiasjakobi-lr]

Hello,

I encountered this behaviour recently after integrating some files in our image by use of archivedir. I had some larger script I wanted to add to the image, and I didn't want to use the embed-into-XML way, because this makes the script hard to test (I need to copy it to a separate file, remove the XML structure, etc.). The script was supposed to go into /etc, so my archivedir has some structure like this myarchivedir/etc/someotherdir/myscript.sh

We also create a non-privileged user in the image, and then try to do some stuff with it, using su -c.

These su -c calls were failing now. Some permission error thing. Investigating further I noticed that even su - mynormaluser was already failing. su told me that it couldn't access the home directory of mynormaluser. But that home dir was definitely there. I then noticed that not only /etc but the root dir as well had all permission 750. Well, that kinda explained why the home dir couldn't be accessed.

Long story short, I tracked this down to the creation and extraction of the archivedir tarball. On this machine the default umask is 0027. This is because we allow other developers access to the machine, but don't want to expose the own files by default. What now happens is the following. ELBE creates the archivedir tarball, but all files going into the archive are not accessible by other. Inside the initvm the tarball is extracted again, over the already existing rootfs. Upon extraction tar adjusts the metadata of the directories it extracts. So in particular / -- which results in / becoming 750 inside the initvm.

I have no idea how to solve this in a clean way. But as we're already adjusting the user and group of the archive files, maybe one could add like a Git-permission-style-sanitation step to the whole thing? Git doesn't know the full Unix permissions. It basically knows regular files and executables. The former is 644 the latter 755 (assuming a 0022 umask). Mapping everything to either 644 or 755 would at least keep / accessible for other.

There is also --no-overwrite-dir as argument for tar when extracting. That would at least keep metadata of existing dirs intact.

With best wishes,
Tobias

[t-8ch]

maybe one could add like a Git-permission-style-sanitation step to the whole thing?

That prevents any form of more elaborate permission adjustments.

There is also --no-overwrite-dir as argument for tar when extracting.

This looks useful in any case, but it probably needs to be gated behind an option, not to break existing users setups.

A general solution would be to create the tar not only from filesystem information but also a manifest file like mtree.
This could be integrated into ELBE proper, but would incur additional complexity.
On the other hand any complex files should be properly packaged as a real Debian package.
And it is also possible to work with the ELBE XML using custom scripts implementing a custom archivedir.

[tobiasjakobi-lr]

Yeah, it's a tricky situation. I was playing around with Git hooks that modify the permissions in the archivedir directory, but that's kind of ugly...

[t-8ch]

Could you take a look at the branch https://github.com/Linutronix/elbe/tree/b4/pbuilder-directory ?
It allows the build of a Debian package from a local directory during package build.
The build will be a bit slower, but it is a "real" solution.

[tobiasjakobi-lr]

Sorry for the late reply. I see that this has already been merged into master. I plan to test this, just not sure when.