FS#58473 - archiso - umask 0077 on build machine causes permission denied in the iso on any binary execution.

Attached to Project: Release Engineering
Opened by Anton Hvornum (Torxed) - Sunday, 06 May 2018, 11:06 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Saturday, 23 June 2018, 22:50 GMT
Task Type Bug Report
Category ArchISO
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

If the machine building the iso has a umask of 0077,
when modifying customize_rootfs.sh (from config/releng) and adding any binary execution (whomai for instance, anywhere in the .sh file) - the execution will return with:

permission denied: /bin/bash

The only way to correct this is to (in customize_rootfs.sh) add:

chmod 755 /

Among other folders, in order to regain execution privileges from within customize_rootfs.sh.
The default chmod is 0022 on a default arch machine, but any "hardening" will mess up the archiso build.

I'm aware that this script was built and tested on a default arch install, and maybe it adds to much complexity to the build script taking care of all the odd edge cases that people set up on their own. But perhaps a second chmod on the airootfs file structure isn't a bad idea?
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Saturday, 23 June 2018, 22:50 GMT
Reason for closing:  Fixed
Additional comments about closing:  v35
Comment by Anton Hvornum (Torxed) - Sunday, 06 May 2018, 11:16 GMT
Alternative (better?) solution:

Temporary set `umask 0022` throughout the execution of archiso build scripts?
Instead of chmod on the file structure, since there might be a lot of places along the way that touches the filesystem and potentially changes it for the worse again.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 11 May 2018, 02:38 GMT
temp set umask to 0022, seems the correct way. But that is your task not from the program/script point of view. Otherwise the "concept" of umask is irrelevant... Imagine if all program do such things. I am sure that you will ask the counterpart...
Comment by Eli Schwartz (eschwartz) - Friday, 11 May 2018, 13:05 GMT
We set the umask in makepkg for this very reason. I don't consider it the responsibility of the user, not when the program/script in question is meant to build a package or ISO system which is *not* supposed to be "based on the system it was created on".

umask is supposed to affect the operation of the system in question, not things which are built on the system but used elsewhere.


https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in?h=v5.0.2#n1776
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 11 May 2018, 13:49 GMT
> which is *not* supposed to be "based on the system it was created on".

100% agree. Good point!. I will add such change. Thanks.
Comment by Gerardo Exequiel Pozzi (djgera) - Tuesday, 15 May 2018, 04:05 GMT
any tested patch is welcomed ;) Thanks.
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 23 June 2018, 19:11 GMT
fixed in git, please test

Loading...