summaryrefslogtreecommitdiff
path: root/meta/classes/useradd-staticids.bbclass
AgeCommit message (Collapse)AuthorFiles
2016-12-16meta: remove True option to getVar callsJoshua Lock1
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\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-10-28useradd-staticids.bbclass: catch missing uid/gid exceptionsMikko Ylinen1
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. Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-10-03useradd-staticids.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson1
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. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-08-01useradd-staticids.bbclass: trigger reparsing when table files changePatrick Ohly1
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 Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-12useradd-staticids: use map() instead of imap()George McCollister1
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. Signed-off-by: George McCollister <george.mccollister@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-17useradd-staticids.bbclass: Allow missing UIDs/GIDs to generate warningsPeter Kjellerstedt1
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. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-17useradd-staticids.bbclass: Restore failure on missing UIDs/GIDsPeter Kjellerstedt1
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] Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-12useradd-staticids.bbclass: Avoid FutureWarning about split()Peter Kjellerstedt1
This avoids the following warning with Python 3.5: /usr/lib64/python3.5/re.py:203: FutureWarning: split() requires a non-empty pattern Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-06-12useradd-staticids.bbclass: Make sure opened files are closedPeter Kjellerstedt1
This avoids warnings about unclosed files with Python 3. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-01-17useradd-staticids.bbclass: Remove unnecessary spacesPeter Kjellerstedt1
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. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-17useradd-staticids.bbclass: Read passwd/group files before parsingPeter Kjellerstedt1
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. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-17useradd-staticids.bbclass: Simplify the logic for when to add groupsPeter Kjellerstedt1
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}. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-17useradd-staticids.bbclass: Simplify some logicPeter Kjellerstedt1
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. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-17useradd-staticids.bbclass: Make --no-user-group have effectPeter Kjellerstedt1
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. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-17useradd-staticids.bbclass: Treat mutually exclusive options as suchPeter Kjellerstedt1
The useradd options --create-home/--no-create-home and --user-group/--no-user-group are mutually exclusive and should be treated as such. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-10-29useradd-staticids.bbclass: Do not require trailing colonsPeter Kjellerstedt1
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. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-09-03useradd-staticids.bbclass: Fix for Bug 6633Fabrice Coulon1
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. Signed-off-by: Fabrice Coulon <fabrice@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-20useradd{-static}: Ignore useradds on nativesdkMark Hatle1
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-11useradd-staticids: Adjust USERADD_ERROR_DYNAMIC condition and error messageMark Hatle1
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-11useradd-staticids: Fix groupadd when --user-group is selectedMark Hatle1
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-08useradd.bbclass: Add ability to select a static uid/gid automaticallyMark Hatle1
[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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>