diff options
author | Peter Kjellerstedt <peter.kjellerstedt@axis.com> | 2016-09-15 17:44:47 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-09-16 15:15:33 +0100 |
commit | 4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f (patch) | |
tree | fe921e670c46b6a1d15052d788ca06eb62accf1e /meta/classes/metadata_scm.bbclass | |
parent | 3226d89ff743c223181fda90f605c7579337941a (diff) | |
download | openembedded-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/metadata_scm.bbclass')
0 files changed, 0 insertions, 0 deletions