| Age | Commit message (Collapse) | Author |
|---|
|
A couple have still been missed in the past despite multiple
attempts at doing so (or simply have re-appeared?).
Search & replace made using the following command:
sed -e 's|\(d\.getVar \?\)( \?\([^,()]*\), \?True)|\1(\2)|g' \
-i $(git grep -E 'getVar ?\( ?([^,()]*), ?True\)' \
| cut -d':' -f1 \
| sort -u)
(From OE-Core rev: 9f551d588693328e4d99d33be94f26684eafcaba)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The new name is much more consistent with what this actually means. We put
the pieces in place to rename everything a while back but looks like we
forgot to actually do it! Fix that now.
(From OE-Core rev: af9612f5d6b848fceea22d10ee964437299be776)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When a distro uses useradd-staticids.bbclass and some developer
unfamiliar with the static ID mechanism tries to add a recipe which
needs new IDs, the resulting error or warning is typically not
something that the developer will understand.
Even experienced developers do not get enough information. They first
must find out whether the missing ID is for a system user or group,
then locate the file(s) in which the ID could be added. Both of this
is now part of the message:
ERROR: .../meta/recipes-extended/cronie/cronie_1.5.1.bb: cronie -
cronie: system groupname crontab does not have a static ID defined.
Add crontab to one of these files: /.../conf/distro/include/my-distro-group
The case that no file was found is also handled:
ERROR: .../meta/recipes-extended/cronie/cronie_1.5.1.bb: cronie -
cronie: system groupname crontab does not have a static ID defined.
USERADD_GID_TABLES file(s) not found in BBPATH: files/group
It would be nice if the error message could also list the range in
which a new ID needs to be allocated, but /etc/login.defs isn't
available at the time of creating the message, so that part is still
something that a developer needs to know.
(From OE-Core rev: 883bfc2bbb4d2120dbad6b0f2056503b012b1a2b)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When enabling useradd-staticids.bbclass, one has to define static IDs
for all recipes in a world build, otherwise those without static IDs
generate parse errors or warnings, depending on USERADD_ERROR_DYNAMIC.
Defining unused IDs is a lot of work and clutters the passwd/group
file of a distro.
Distros which want to avoid this can now set USERADD_ERROR_DYNAMIC =
"skip" and recipes which would have triggered a message then silently
get disabled. Only trying to build them shows the error message:
$ bitbake apt
...
ERROR: Nothing PROVIDES 'apt'
ERROR: apt was skipped: apt - apt: username _apt does not have a static ID defined.
(From OE-Core rev: 9113928cea88c2187e8640ac489671cb81f58103)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Adding distcc to an image, and having staticids enabled,
doesn't work as it causes a a superfluous 'distcc' group
being added using a conflicting GID, thus failing the
build:
| ERROR: distcc-3.2-r0 do_prepare_recipe_sysroot: distcc: groupadd command did not succeed.
Compared to other recipes, the distcc recipe only
specifies --gid for the primary group, and doesn't specify
--no-user-group, but when --gid is given, it doesn't make
sense to create a matching username-group in addition,
even if --no-user-group was not specified, and 'useradd'
actually complains if --gid and --user-group are given
both.
If only --gid is given, the current code in here
effectively behaves as if --user-group was specified,
taking the group-id of the username-group from the
--gid parameter. This causes the error above, as we try
to add a new group (distcc) with an existing group-id
(nogroup).
This is contrary to the comment in this file just above,
contrary to what useradd can do, contrary to behaviour
without the useradd-staticids bbclass, and non-intuitive.
Change the code such that a username-group is only created
- if a primary group using --gid was not specified, or
- if --no-user-group was not specified
To be in line with useradd, if gid is not given, and
--no-user-group is given, we add the user to the group
'users', which mimics useradd's behaviour.
(From OE-Core rev: fc3a86ae68919cec72c1a8ae0f9ba1f98ae13f0d)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The code in useradd-staticids is generally useful for user addition
functionality but is not reusable in its current form. Refactor the
code into a set of library functions.
(From OE-Core rev: a638ef304b1f1acb4c88f4f90b1ef22526cb8d2f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The commit 31dee7946340bf0f1e94e4e714191d3d6ca3bf6a added a new useradd and
groupadd option to specify a clear text password. The parsing logic in the
useradd-staticid class did not understand this new option. If the
meta-skeleton examples were run with the class enabled an error would be
generated, as an example uses the -P option.
Note, the code has a check that we do not attempt to set both a crypt and
clear text password. It is not allowed that these two options are set
at the same time, so we prefer the crypt option if they happen to be.
(From OE-Core rev: a1715970d5c454dd24d04972ffb9cf735b5d1338)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Previously, with USERADD_ERROR_DYNAMIC set to error/warn, if a static
UID/GID was specified in the recipe, then no error/warning would be
issued even if no ID was specified in the passwd/groups files.
(From OE-Core rev: 8e4b4e28a7c3a9dbd6b9298bea5d2c1328b3f24a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If this bbclass is used and a recipe specifies a static ID for a
user/group as part of the USERADD_PARAM_${PN} or GROUPADD_PARAM_${PN},
the build would fail with and error like this if there was no
corresponding ID in the passwd/group files specified via
USERADD_UID_TABLES/USERADD_GID_TABLES:
ERROR: meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb:
meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb inherits
useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or
GROUPMEMS_PARAM for package postgresql
(From OE-Core rev: e744fac05fc5cc19cabc59c1e79ff4c1b3ee396d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is a typo in the useradd-staticids.bbclass that
causes error during do_install.
If build was configured to use usedadd-staticids and
the recipe included (for example):
USERADD_PARAM_${PN} = "--expiredate '' testUser"
Due to the typo this added the wrong option '--expiredata '
that caused an error.
(From OE-Core rev: 9d26a2f9f52ae9df6aa5e0ee20683ada35c32af1)
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When a group name is duplicated between USERADD_PARAM and
GROUPADD_PARAM, this class tries to add it twice which results in
failure of the groupadd command.
(From OE-Core rev: 5b84cc895500c28674d2a7b7c2dd618cf8fb30e9)
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When creating users at the image level using extrausers class, the
current behavior is to ignore the status of USERADDEXTENSION. This could
lead to undefined behavior when static ids are expected but the system
falls back to dynamic ones.
(From OE-Core rev: 331140e892f84b70bced44a0b5d14f32ec95042e)
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The change to get rid of FuncFailed exceptions changed the behavior
of how missing uid/gid error are be handled. Instead of catching
the exception and handling that via bb.parse.SkipPackage(), a fatal
error was called.
This won't work with recipes that are unused and therefore do not have
UID/GIDs defined. The problem triggers when parsing all recipes (e.g.,
oe-selftest runs bitbake -p).
The right way to handle this is to raise bb.parse.SkipPackage(). This
will error correctly once the recipe is needed.
(From OE-Core rev: 55384cfc743a12a78bef736ee08ed453b6a6a21e)
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: e507cb978fd52164beb28324933cb3d5e368c3ab)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This addresses (among others) the following problem:
- USERADD_ERROR_DYNAMIC=error causes a recipe to get skipped
because a static ID entry is missing
- the entry gets added to the file
- using the recipe still fails with the same error as before
because the recipe gets loaded from the cache instead
of re-parsing it with the new table content
(From OE-Core rev: 799c93592a9aac571d6dc05529437c0eec7b08b8)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In Python3 the itertools module's imap function has been migrated to the
globalname space as map(). Calling itertools.imap() will fail because it
no longer exists.
(From OE-Core rev: da7a2c7b00b40a8759dbe9f4ab6df3e337e3d6b6)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Previously when USERADD_ERROR_DYNAMIC was set to "1", an exception was
raised if no numeric UID/GID could be determined for a user/group. Now
it is possible to set it to either "error", which results in the old
behavior, or "warn" in which case a warning is issued instead.
For backwards compatibility reasons, it is still possible to set
USERADD_ERROR_DYNAMIC to "1" and get an exception in case of failure.
(From OE-Core rev: 58c82f79efee8e68fa63b96a32f54660afb15769)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
A regression was introduced with commit 3149319a whereby setting
USERADD_ERROR_DYNAMIC no longer resulted in an error for users and
groups that were missing numeric UIDs and GIDs but were not mentioned
at all in any passwd or groups file.
[YOCTO #9777]
(From OE-Core rev: adc0f830a695c417b4d282fa580c5231e1f0afbe)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This avoids the following warning with Python 3.5:
/usr/lib64/python3.5/re.py:203: FutureWarning: split() requires a
non-empty pattern
(From OE-Core rev: a7a783c30cc58008f0e070dad39d40038e0a5eb5)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This avoids warnings about unclosed files with Python 3.
(From OE-Core rev: 77adf8341694b76cf58b7a31dda18b85b3eb87a2)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This removes unnecessary spaces inserted before semicolons in the
modified USERADD_PARAM_${PN} and GROUPADD_PARAM_${PN} variables. This
should not affect the handling of the variables as the only one that
actually sees the semicolons is the code in useradd.bbclass that uses
cut to split the variables at them, and any whitespace preceeding or
following the semicolons will be properly ignored.
(From OE-Core rev: acc17ef91a6f506e3cacdc0d4ebfa268b3f3affd)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Read and merge the passwd/group files before parsing the user and
group definitions. This means they will only be read once per
recipe. This solves a problem where if a user was definied in multiple
files, it could generate group definitions for groups that should not
be created. E.g., if the first passwd file read defines a user as:
foobar::1234::::
and the second passwd file defines it as:
foobar:::nogroup:The foobar user:/:/bin/sh
then a foobar group would be created even if the user will use the
nogroup as its primary group.
(From OE-Core rev: 3149319ad997379a01d87f2b1b5d14f66541997f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The original code was near impossible to follow, and missed a couple
of cases. For example, if one added the following line to the passwd
file specified in USERADD_UID_TABLES:
foobar:x:12345:nogroup::/:/bin/sh
and then specified the user as:
USERADD_PARAM_${PN} = "--system foobar"
one would then assume that the foobar user would be created with the
primary group set to nogroup. However, it was not (the primary group
would be foobar), and the only way to get it correct was to explicitly
add --gid nogroup to the USERADD_PARAM_${PN}.
(From OE-Core rev: e98e98ce65cf9ffdef29462310a622ffddd1412b)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The [<on_true>, <on_false>][not <condition>] construct may solve the
problem of implementing a conditional operator, but it is not very
readable. At least I find this:
uaargs.groupid = field[3] or uaargs.gid or uaargs.groupname
a lot more readable than this:
uaargs.groupid = [uaargs.gid, uaargs.groupname][not uaargs.gid]
uaargs.groupid = [field[3], uaargs.groupid][not field[3]]
Also, the official conditional operator since Python 2.5 (<on_true> if
<condition> else <on_false>) does not evaluate both <on_false> and
<on_true> as [<on_true>, <on_false>][not <condition>] does.
(From OE-Core rev: 274d38a6e2183ec88335a08b963f26c34b328558)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If --no-user-group is specified in USERADD_PARAM_${PN} for a user and
no --gid is specified, then we should not assume that the group name
for the user is the user name.
(From OE-Core rev: 0e5402c433739a416a76df532378533cb25365c7)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The useradd options --create-home/--no-create-home and
--user-group/--no-user-group are mutually exclusive and should be
treated as such.
(From OE-Core rev: 908eca7fb4af8a60026f53e2bb2cf1d5daf089ab)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Before, the users and groups specified in the passwd file and the
groups file had to have trailing colons to make sure there were enough
elements in the definitions, or bitbake would throw a Python
exception. After this change one can omit the trailing colons, which
especially simplifies passwd files used only to specify static UIDs.
(From OE-Core rev: 7754e0f71eb794f0e06a1b005e3824fac4cdac6c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When using the useradd-staticids.bbclass under meta/classes,
this error occurs:
"<username> - <username>: Username does not have a static uid defined."
There was a problem with the regular expression for parsing parameters,
it was sometimes returning an empty string.
I have fixed this by skipping empty strings.
(From OE-Core rev: f249ef32709069a2680b92dc5a5b4f6545d014b7)
Signed-off-by: Fabrice Coulon <fabrice@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The code was supposed to ignore both native and nativesdk operations when
using the useradd and useradd-static code. However, somewhere along the way
the code was dropped. This didn't cause any issues until someone enabled the
enforcing mode in the new useradd-static and various nativesdk packages
started to fail.
(From OE-Core rev: 6b9705892400a1da1fcd973c64d1911c7c4463f6)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The USERADD_ERROR_DYNAMIC needs to check that both users and groups that are
defined need to be represented as static ids, or an error should occur.
For the user check, we want to make sure the uid is a numeric value. (The gid
can be name, as the GROUPADD check will validate for a number there -- or
during install useradd will fail if that group is not defined.)
For the group check, we verify that the gid is specified and not left as a name.
Also two statements that can be uncommented for debugging were added so that
future development work on this code would be easier to do.
(From OE-Core rev: f35bbba65e3e41f8dea1f9ff872d3a9fbd84bf6d)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When --user-group is selected (it's on by default as well) we want
to translate that to a groupname and disable the --user-group. Before
we just disabled --user-group, but didn't always add the group to the
system.
This change ensures that we add the group (as long as we have enough
information to actually add the group), and we disable --user-group
in that case. If a static groupid is not specified we continue to
use the groupname, but via an explicit groupadd.
(From OE-Core rev: ae83db0fdcf0b807ffdfc901f4d1c463fffee82a)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #5436]
Automatic selection of static uid/gid is needed for a dynamically generated
passwd and group file to have a deterministic outcome.
When a package is installed and instructs the system to add a new user or
group, unless it selects a static uid/gid value, the next available uid/gid
will be used. The order in which packages are installed is dynamically
computed, and may change from one installation to the next. This results
in a non-deterministic set of uid/gid values.
Enabling this code by adding USERADDEXTENSION = "useradd-staticids", and
adding a preconfigured passwd/group file will allow the continued dynamic
generation of the rootfs passwd/group files, but will ensure a deterministic
outcome. (Dynamic generation is desired so that users and groups that have
no corresponding functionality are not present within the final system image.)
The rewrite params function will override each of the fields in the
useradd and groupadd calls with the values specified. Note, the password
field is ignored as is the member groups field in the group file. If the
field is empty, the value will not be overridden. (Note, there is no way
to 'blank' a field, as this would only generally affect the 'comment' field
and there really is no reason to blank it.)
Enabling USERADD_ERROR_DYNAMIC will cause packages without static uid/gid
to generate an error and be skipped for the purpose of building. This is
used to prevent non-deterministic behavior.
USERADD_UID_TABLES and USERADD_GID_TABLES may be used to specify the name
of the passwd and group files. By default they are assumed to be
'files/passwd' and 'files/group'. Layers are searched in BBPATH order.
(From OE-Core rev: 18c99dac52b746b88cd084eb4c2a2ef0329a6ff3)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
André Draszik
Richard Purdie
Patrick Ohly
André Draszik
Mark Hatle
Peter Kjellerstedt
Peter Bergin
David Vincent
Joshua Lock
Mikko Ylinen
Ulf Magnusson
George McCollister
Fabrice Coulon