summaryrefslogtreecommitdiffstats
path: root/meta/classes/chrpath.bbclass
diff options
context:
space:
mode:
authorPeter Kjellerstedt <peter.kjellerstedt@axis.com>2016-09-15 17:44:47 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2016-09-16 15:24:03 +0100
commitde154f0289b5e3498cb3a1102d144ee42bfac90c (patch)
tree9904c8af736f17df54cf4195ba6771d09dd670f7 /meta/classes/chrpath.bbclass
parenta4f10da74ae3b91af403f9ee1a2d94e0a1795224 (diff)
downloadpoky-de154f0289b5e3498cb3a1102d144ee42bfac90c.tar.gz
useradd_base.bbclass: Do not mess with the gshadow file in the sysroot
Previously, if the gshadow file did not exist in the sysroot when perform_groupmems() was run, it would be temporarily created and removed again afterwards. This was supposedly due to groupmems failing if it does not exist. However, based on empirical testing and examination of the source code for groupmems, it should not fail if the gshadow file does not exist when groupmems is started. But it WILL fail if the file is removed sometime after its existence has been check at the beginning of the execution, but before it needs to be modified. And this is exactly what the previous code in perform_groupmems() could cause if multiple tasks simultaneously modified users or groups. It could cause any of the useradd, groupadd and groupmems commands to fail as long as at least one other recipe invoked perform_groupmems(). (From OE-Core rev: 4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/chrpath.bbclass')
0 files changed, 0 insertions, 0 deletions