summaryrefslogtreecommitdiffstats
path: root/meta/classes/useradd-staticids.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* useradd-staticids: don't create username-group if gid is specifiedAndré Draszik2017-09-251-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* useradd: Create lib/oe/useradd function libraryRichard Purdie2017-05-161-64/+8
| | | | | | | | | | | 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>
* useradd-statids.bbclass: Add support for -P / --clear-password optionMark Hatle2017-04-291-2/+10
| | | | | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Always fail/warn for missing IDsPeter Kjellerstedt2017-03-221-4/+2
| | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Support recipes specifying static IDsPeter Kjellerstedt2017-03-221-0/+2
| | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids: fix typo for '--expiredate'Peter Bergin2017-02-231-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids: Fix groupaddDavid Vincent2017-01-261-1/+3
| | | | | | | | | | | 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>
* extrausers: Use static ids when availableDavid Vincent2017-01-191-6/+31
| | | | | | | | | | | | | 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>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-24/+24
| | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: catch missing uid/gid exceptionsMikko Ylinen2016-10-281-3/+2
| | | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Use bb.fatal() instead of raising FuncFailedUlf Magnusson2016-10-041-4/+4
| | | | | | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: trigger reparsing when table files changePatrick Ohly2016-08-011-0/+13
| | | | | | | | | | | | | | | | 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>
* useradd-staticids: use map() instead of imap()George McCollister2016-07-121-1/+1
| | | | | | | | | | | 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>
* useradd-staticids.bbclass: Allow missing UIDs/GIDs to generate warningsPeter Kjellerstedt2016-06-171-1/+4
| | | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Restore failure on missing UIDs/GIDsPeter Kjellerstedt2016-06-171-6/+13
| | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Avoid FutureWarning about split()Peter Kjellerstedt2016-06-121-2/+2
| | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Make sure opened files are closedPeter Kjellerstedt2016-06-121-13/+17
| | | | | | | | | | 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>
* useradd-staticids.bbclass: Remove unnecessary spacesPeter Kjellerstedt2016-01-181-3/+3
| | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Read passwd/group files before parsingPeter Kjellerstedt2016-01-181-73/+91
| | | | | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Simplify the logic for when to add groupsPeter Kjellerstedt2016-01-181-20/+16
| | | | | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Simplify some logicPeter Kjellerstedt2016-01-181-8/+7
| | | | | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Make --no-user-group have effectPeter Kjellerstedt2016-01-181-1/+1
| | | | | | | | | | | 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>
* useradd-staticids.bbclass: Treat mutually exclusive options as suchPeter Kjellerstedt2016-01-181-13/+14
| | | | | | | | | | | 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>
* useradd-staticids.bbclass: Do not require trailing colonsPeter Kjellerstedt2015-10-291-2/+14
| | | | | | | | | | | | | | 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>
* useradd-staticids.bbclass: Fix for Bug 6633Fabrice Coulon2014-09-031-2/+6
| | | | | | | | | | | | | | | 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>
* useradd{-static}: Ignore useradds on nativesdkMark Hatle2014-03-211-1/+2
| | | | | | | | | | | | | 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>
* useradd-staticids: Adjust USERADD_ERROR_DYNAMIC condition and error messageMark Hatle2014-02-111-3/+5
| | | | | | | | | | | | | | | | | | | 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>
* useradd-staticids: Fix groupadd when --user-group is selectedMark Hatle2014-02-111-20/+30
| | | | | | | | | | | | | | | | | 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>
* useradd.bbclass: Add ability to select a static uid/gid automaticallyMark Hatle2014-02-091-0/+259
[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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-10 10:54:27 +0000