9262 2016-03-15 13:43:36 +0000 useradd class doesn't clean properly 2016-05-04 11:50:56 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified All Multiple RESOLVED FIXED Medium+ normal 2.1 M4 1 gary maxin.john jku maxin.baby.john maxin.john meta.mr.watcher meta.watcher richard.purdie valentinx.hangan valentinx.hangan --- --- Don't know oldest_to_newest 59972 0 gary 2016-03-15 13:43:36 +0000 If a recipe is built that creates user(s) via useradd.bbclass, those users are not removed (at least from sysroot) when the recipe/package is cleaned, even using cleanall. This can lead to confusion, in particular if the recipe is changed in a way that affects how the user(s) are created because they won't be recreated when the recipe is rebuilt. For example if the recipe creates a user with no explicit --uid/--gid parameters, those parameters will be ignored if they are later added to the recipe and rebuilt. Note: this may also be related to bug #7724 59999 1 jku 2016-03-16 08:19:30 +0000 Maxin was just looking at this or something very much like it -- CCing just in case. 60003 2 maxin.john 2016-03-16 11:12:40 +0000 Fedora User account handling policy says: ( https://fedoraproject.org/wiki/Packaging:UsersAndGroups ) " Do not remove users or groups We never remove users or groups created by packages. There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do with them?) and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups deleting the user/group might not be possible or/nor desirable (eg. when using a shared, remote user/group database). Cleanup of unused users/groups is left to the system administrators to take care of if they so desire. " Debian also has similar policy: ( https://wiki.debian.org/AccountHandlingInMaintainerScripts ) " Technical Issues of account removal Deleting an account is significantly harder than creating it because of the following reasons: at package purge time, a package can no longer rely on its dependencies being installed the local admin might have decided to chown unrelated files to the package account if we remove the account on purge, it is possible that the UID will be re-used at some later time " Also Yocto #8078 describes a use-case where "Package A" depends on user created by "Package B". If we remove the user along with "Package B", then, we might end up with a broken "Package A" in the device. 60004 3 gary 2016-03-16 11:27:30 +0000 (In reply to comment #2) > Fedora User account handling policy says: > ( https://fedoraproject.org/wiki/Packaging:UsersAndGroups ) > " > Do not remove users or groups > > We never remove users or groups created by packages. There's no sane way to > check if files owned by those users/groups are left behind (and even if > there would, what would we do with them?) and leaving those behind with > ownerships pointing to now nonexistent users/groups may result in security > issues when a semantically unrelated user/group is created later and reuses > the UID/GID. Also, in some setups deleting the user/group might not be > possible or/nor desirable (eg. when using a shared, remote user/group > database). Cleanup of unused users/groups is left to the system > administrators to take care of if they so desire. > " > > Debian also has similar policy: > ( https://wiki.debian.org/AccountHandlingInMaintainerScripts ) > > " > Technical Issues of account removal > > Deleting an account is significantly harder than creating it because of the > following reasons: > > at package purge time, a package can no longer rely on its dependencies > being installed > the local admin might have decided to chown unrelated files to the package > account > if we remove the account on purge, it is possible that the UID will be > re-used at some later time > " > > Also Yocto #8078 describes a use-case where "Package A" depends on user > created by "Package B". If we remove the user along with "Package B", then, > we might end up with a broken "Package A" in the device. So how does one handle the scenario as described? It seems a bit harsh to have to wipe "tmp" and start over, if that even works... 60007 4 gary 2016-03-16 12:20:14 +0000 (In reply to comment #3) > (In reply to comment #2) > > Fedora User account handling policy says: > > ( https://fedoraproject.org/wiki/Packaging:UsersAndGroups ) > > " > > Do not remove users or groups > > > > We never remove users or groups created by packages. There's no sane way to > > check if files owned by those users/groups are left behind (and even if > > there would, what would we do with them?) and leaving those behind with > > ownerships pointing to now nonexistent users/groups may result in security > > issues when a semantically unrelated user/group is created later and reuses > > the UID/GID. Also, in some setups deleting the user/group might not be > > possible or/nor desirable (eg. when using a shared, remote user/group > > database). Cleanup of unused users/groups is left to the system > > administrators to take care of if they so desire. > > " > > > > Debian also has similar policy: > > ( https://wiki.debian.org/AccountHandlingInMaintainerScripts ) > > > > " > > Technical Issues of account removal > > > > Deleting an account is significantly harder than creating it because of the > > following reasons: > > > > at package purge time, a package can no longer rely on its dependencies > > being installed > > the local admin might have decided to chown unrelated files to the package > > account > > if we remove the account on purge, it is possible that the UID will be > > re-used at some later time > > " > > > > Also Yocto #8078 describes a use-case where "Package A" depends on user > > created by "Package B". If we remove the user along with "Package B", then, > > we might end up with a broken "Package A" in the device. > > So how does one handle the scenario as described? It seems a bit harsh to > have to wipe "tmp" and start over, if that even works... To follow up on this, OE is not Debian nor Fedora. What I mean is that in those environments, single packages are built and the build system knows nothing of package interdependencies. OE on the other hand knows all about such things and it should be no big problem that if a package causes the removal of a user/group ID then any dependent packages would be also marked appropriately so they will be rebuilt/reinstalled. I don't know how "hard" this is to make happen, but the fact that it can be done and it makes the build system more "correct", then that's how it should behave. 60075 5 maxin.john 2016-03-17 12:29:22 +0000 (In reply to comment #3) > > So how does one handle the scenario as described? It seems a bit harsh to > have to wipe "tmp" and start over, if that even works... We don't need to wipe "tmp" directory for that. # bitbake -c cleansstate base-passwd should do it. However,that method also has some problems at the moment(Please see bug #8759) 60208 6 3049 maxin.john 2016-03-21 15:18:24 +0000 Created attachment 3049 userdel_sysroot_sstate patch This patch provides a function which cleans-up users/groups during cleansstate/cleanall task. 60209 7 maxin.john 2016-03-21 15:21:24 +0000 Please let me know if this is an acceptable fix. 60268 8 gary 2016-03-22 07:33:27 +0000 (In reply to comment #7) > Please let me know if this is an acceptable fix. Yes, this does seem to solve the issue I was having. I created my package then reran bitbake after altering the useradd settings in the recipe and the changes worked as desired unlike before where nothing happened the second time around. 60270 9 maxin.baby.john 2016-03-22 08:57:24 +0000 (In reply to comment #8) > (In reply to comment #7) > > Please let me know if this is an acceptable fix. > > Yes, this does seem to solve the issue I was having. I created my package > then reran bitbake after altering the useradd settings in the recipe and the > changes worked as desired unlike before where nothing happened the second > time around. Thanks a lot! Fix sent to oe-core mailing list: http://lists.openembedded.org/pipermail/openembedded-core/2016-March/119264.html 60600 10 richard.purdie 2016-03-31 14:06:07 +0000 We really need to have this removal code run at any of the points sstate_clean() is called. This means the user would be removed for do_clean, when a version is upgraded and the sysroot is cleaned out during do_configure and so on. I talked with Maxin about this and have some pointers as to how we might be able to add some hooks to sstate_clean to make this work. If we don't do this, I worry we'll only fix the issue for some cases and not all. 60786 11 maxin.john 2016-04-05 07:36:38 +0000 v2 sent to oe-core ML: http://lists.openembedded.org/pipermail/openembedded-core/2016-April/119879.html 60885 12 maxin.john 2016-04-07 07:55:25 +0000 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=cbe33ecb15f71737354184cd9f3b7507ab97b2e4 3049 2016-03-21 15:18:24 +0000 2016-03-21 15:18:24 +0000 userdel_sysroot_sstate patch 0001-useradd.bbclass-remove-user-group-created-by-the-pac.patch text/plain 2168 maxin.john RnJvbSBiMWRiZjhjYzdjMTNjYTM1MWFmYzYxMTNhZGNhODJjODExOWEzMTdmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiAiTWF4aW4gQi4gSm9obiIgPG1heGluLmpvaG5AaW50ZWwuY29t PgpEYXRlOiBNb24sIDIxIE1hciAyMDE2IDE3OjAyOjEwICswMjAwClN1YmplY3Q6IFtQQVRDSF0g dXNlcmFkZC5iYmNsYXNzOiByZW1vdmUgdXNlci9ncm91cCBjcmVhdGVkIGJ5IHRoZSBwYWNrYWdl IGluCiBjbGVhbmFsbCB0YXNrCgpBdCBwcmVzZW50LCBpZiBhIHJlY2lwZSBpcyBidWlsdCB3aGlj aCBjcmVhdGVzIHVzZXJzL2dyb3VwcyB2aWEgdXNlcmFkZC5iYmNsYXNzLAp0aG9zZSB1c2Vycy9n cm91cHMgYXJlIG5vdCByZW1vdmVkIChhdCBsZWFzdCBmcm9tIHN5c3Jvb3QpIHdoZW4gdGhlCnJl Y2lwZS9wYWNrYWdlIGlzIGNsZWFuZWQgdXNpbmcgY2xlYW5zc3RhdGUvY2xlYW5hbGwuCgpUaGlz ICJ1c2VyZGVsX3N5c3Jvb3Rfc3N0YXRlKCkiIHByb3ZpZGVzIHRoYXQgZnVuY3Rpb25hbGl0eS4g UGxlYXNlIG5vdGUKdGhhdCB0aGlzIGZ1bmN0aW9uIGRvZXMgbm90IGFmZmVjdCB0aGUgdXNlcnMv Z3JvdXBzIGNyZWF0ZWQgaW4gdGhlIGZpbmFsCnJvb3QgZmlsZXN5c3RlbS4KCltZT0NUTyAjOTI2 Ml0KClNpZ25lZC1vZmYtYnk6IE1heGluIEIuIEpvaG4gPG1heGluLmpvaG5AaW50ZWwuY29tPgot LS0KIG1ldGEvY2xhc3Nlcy91c2VyYWRkLmJiY2xhc3MgfCAyNSArKysrKysrKysrKysrKysrKysr KysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMjUgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL21l dGEvY2xhc3Nlcy91c2VyYWRkLmJiY2xhc3MgYi9tZXRhL2NsYXNzZXMvdXNlcmFkZC5iYmNsYXNz CmluZGV4IDBhNmYyYmUuLmQ2OTQ4ZTAgMTAwNjQ0Ci0tLSBhL21ldGEvY2xhc3Nlcy91c2VyYWRk LmJiY2xhc3MKKysrIGIvbWV0YS9jbGFzc2VzL3VzZXJhZGQuYmJjbGFzcwpAQCAtMTI3LDYgKzEy NywzMSBAQCB1c2VyYWRkX3N5c3Jvb3Rfc3N0YXRlICgpIHsKIAlmaQogfQogCit1c2VyZGVsX3N5 c3Jvb3Rfc3N0YXRlICgpIHsKKyAgICBleHBvcnQgUFNFVURPPSIke0ZBS0VST09URU5WfSBQU0VV RE9fTE9DQUxTVEFURURJUj0ke1NUQUdJTkdfRElSX1RBUkdFVH0ke2xvY2Fsc3RhdGVkaXJ9L3Bz ZXVkbyAke1NUQUdJTkdfRElSX05BVElWRX0ke2JpbmRpcn0vcHNldWRvIgorICAgIE9QVD0iLS1y b290ICR7U1RBR0lOR19ESVJfVEFSR0VUfSIKKworICAgICMgQWRkIGdyb3VwcyBhbmQgdXNlcnMg ZGVmaW5lZCBmb3IgcGFja2FnZQorICAgIEdST1VQQUREX1BBUkFNPSIke0BnZXRfYWxsX2NtZF9w YXJhbXMoZCwgJ2dyb3VwYWRkJyl9IgorICAgIFVTRVJBRERfUEFSQU09IiR7QGdldF9hbGxfY21k X3BhcmFtcyhkLCAndXNlcmFkZCcpfSIKKworICAgIGlmIHRlc3QgInhgZWNobyAkVVNFUkFERF9Q QVJBTSB8IHRyIC1kICdbOnNwYWNlOl0nYCIgIT0gIngiOyB0aGVuCisgICAgICAgIHVzZXI9YGVj aG8gIiRVU0VSQUREX1BBUkFNIiB8IGN1dCAtZCAnOycgLWYgMSB8IGF3ayAneyBwcmludCAkTkYg fSdgCisgICAgICAgIHBlcmZvcm1fdXNlcmRlbCAiJHtTVEFHSU5HX0RJUl9UQVJHRVR9IiAiJE9Q VCAkdXNlciIKKyAgICBmaQorCisgICAgaWYgdGVzdCAieGBlY2hvICRHUk9VUEFERF9QQVJBTSB8 IHRyIC1kICdbOnNwYWNlOl0nYCIgIT0gIngiOyB0aGVuCisgICAgICAgIGdyb3VwPWBlY2hvICIk R1JPVVBBRERfUEFSQU0iIHwgY3V0IC1kICc7JyAtZiAxIHwgYXdrICd7IHByaW50ICRORiB9J2AK KyAgICAgICAgcGVyZm9ybV9ncm91cGRlbCAiJHtTVEFHSU5HX0RJUl9UQVJHRVR9IiAiJE9QVCAk Z3JvdXAiCisgICAgZmkKK30KKworZG9fY2xlYW5zc3RhdGVbcHJlZnVuY3NdICs9ICIke1NZU1JP T1RDTEVBTkZVTkN9IgorU1lTUk9PVENMRUFORlVOQyA9ICJ1c2VyZGVsX3N5c3Jvb3Rfc3N0YXRl IgorU1lTUk9PVENMRUFORlVOQ19jbGFzcy1jcm9zcyA9ICIiCitTWVNST09UQ0xFQU5GVU5DX2Ns YXNzLW5hdGl2ZSA9ICIiCitTWVNST09UQ0xFQU5GVU5DX2NsYXNzLW5hdGl2ZXNkayA9ICIiCisK IGRvX2luc3RhbGxbcHJlZnVuY3NdICs9ICIke1NZU1JPT1RGVU5DfSIKIFNZU1JPT1RGVU5DID0g InVzZXJhZGRfc3lzcm9vdCIKIFNZU1JPT1RGVU5DX2NsYXNzLWNyb3NzID0gIiIKLS0gCjIuNC4w Cgo=