summaryrefslogtreecommitdiff
path: root/meta/classes/syslinux.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:15:33 +0100
commit4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f (patch)
treefe921e670c46b6a1d15052d788ca06eb62accf1e /meta/classes/syslinux.bbclass
parent3226d89ff743c223181fda90f605c7579337941a (diff)
downloadopenembedded-core-4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f.tar.gz
openembedded-core-4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f.tar.bz2
openembedded-core-4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f.zip
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(). Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/syslinux.bbclass')
0 files changed, 0 insertions, 0 deletions