Have you checked ReadtheDocs?: Yes
Describe the Issue
In 4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive, the replace task builds its replacement string as '{{ item.line }} 027', where item.line already contains the full directive including the umask value (e.g. UMASK {{ amzn2023cis_umask }}). Because the value is supplied by item.line and a literal " 027" is appended, the resulting directive carries two values instead of one.
This produces a malformed UMASK entry in /etc/login.defs and a malformed umask command in /etc/bashrc and /etc/profile. This happens whether you define amzn2023cis_umask or use the default value.
Expected Behavior
Each file should end up with a single, valid directive using the configured umask:
/etc/login.defs -> UMASK 027
/etc/bashrc, /etc/profile -> umask 027
Actual Behavior
Two values are written:
/etc/login.defs -> UMASK 027 027 (or UMASK <amzn2023cis_umask> 027)
/etc/bashrc, /etc/profile -> umask 027 027
/etc/login.defs:
$ grep UMASK /etc/login.defs
# UMASK 027 027is also used by useradd(8) and newusers(8) to set the mode for new
UMASK 027 027
# If HOME_MODE is not set, the value of UMASK 027 027is used to create the mode.
/etc/bashrc:
# By default, we want umask 027 027to get set. This sets it for non-login shell.
# Current threshold for system reserved uid/gids is 200
# You could check uidgid reservation validity in
# /usr/share/doc/setup-*/uidgid file
if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
umask 027 027
else
umask 027 027
fi
In login.defs this is a malformed directive. It looks to me like the first value is still used despite this. In the shell rc files, the resulting umask 027 027 is an invalid command.
Control(s) Affected
4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive
Environment (please complete the following information):
- branch being used: 1.3.0 from ansible galaxy
- Ansible Version: [e.g. 2.21.0]
- Host Python Version: N/A
- Ansible Server Python Version: N/A
Possible Solution
Drop the appended literal so the replacement is just the configured line:
replace: '{{ item.line }}'
(The regexp (?i)(umask\s+\d*) is also broader than needed. \d* and case-insensitivity cause it to match UMASK mentions in comments too, but this doesn't really affect anything other than looking weird.)
Have you checked ReadtheDocs?: Yes
Describe the Issue
In
4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive, thereplacetask builds its replacement string as'{{ item.line }} 027', whereitem.linealready contains the full directive including the umask value (e.g.UMASK {{ amzn2023cis_umask }}). Because the value is supplied byitem.lineand a literal" 027"is appended, the resulting directive carries two values instead of one.This produces a malformed
UMASKentry in/etc/login.defsand a malformedumaskcommand in/etc/bashrcand/etc/profile. This happens whether you defineamzn2023cis_umaskor use the default value.Expected Behavior
Each file should end up with a single, valid directive using the configured umask:
/etc/login.defs->UMASK 027/etc/bashrc,/etc/profile->umask 027Actual Behavior
Two values are written:
/etc/login.defs->UMASK 027 027(orUMASK <amzn2023cis_umask> 027)/etc/bashrc,/etc/profile->umask 027 027/etc/login.defs:/etc/bashrc:In
login.defsthis is a malformed directive. It looks to me like the first value is still used despite this. In the shell rc files, the resultingumask 027 027is an invalid command.Control(s) Affected
4.6.5 | PATCH | Ensure default user umask is 027 or more restrictive
Environment (please complete the following information):
Possible Solution
Drop the appended literal so the replacement is just the configured line:
(The regexp
(?i)(umask\s+\d*)is also broader than needed.\d*and case-insensitivity cause it to matchUMASKmentions in comments too, but this doesn't really affect anything other than looking weird.)