5675 2013-12-17 07:35:31 +0000 Document adding a ROOT_PASSWD feature for images 2021-09-17 01:30:46 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified x86 Multiple RESOLVED WONTFIX Medium enhancement 3.4 M4 1 lpapp michael.opdenacker bevenson bluelightning maciej.pijanowski meta.mr.watcher meta.watcher Qi.Chen randy.macleod richard.purdie --- --- Yes (doc changes required) oldest_to_newest 39442 0 lpapp 2013-12-17 07:35:31 +0000 Currently, one needs to use "usermod -p ..." with EXTRA_USERS_PARAMS, but this is a bit raw. Since, it is a common operation for images that the root password is not left blank by default, I would propose a dedicated feature, and hence variable for this as mentioned in the summary. 39998 1 bevenson 2014-01-22 14:48:20 +0000 If I remember correctly, "usermod -p" expects a DES encrypted password which is limited to 8 characters. For users that want to use a longer root password, I think we'd want a different mechanism for setting the password. Maybe have ROOT_PASSWD accept a string like "encryption_type:cleartext_password" that can be used for calling passwd or chpasswd? 40065 2 lpapp 2014-01-28 16:50:13 +0000 I would prefer ROOT_PASSWORD_type like syntax instead for such features. I like avoiding "raw strings" as much as possible, and would prefer put the qualifier into the variable. 40104 3 bevenson 2014-01-30 13:43:22 +0000 Using a ROOT_PASSWD_type syntax does make more sense. I propose the following: 1. ROOT_PASSWD_des uses DES encryption. This will then be limited to 8 character passwords. The user will be able to put in a password longer than 8 characters, but the system will truncate it to the first 8 characters and post a QA warning that the password was truncated. 2. ROOT_PASSWD defaults to ROOT_PASSWD_des. 3. ROOT_PASSWD_md5 used MD5 encryption. 4. ROOT_PASSWD declarations expects a plaintext password. It is expected that the ROOT_PASSWD declaration will occur in an image recipe, which for a custom system belongs in a user's private layer. This means the root password can be kept safe from those who are not expected to know the root password. 5. If multiple ROOT_PASSWD declarations exits, only the last one is used. For example, if an image recipe contains: ROOT_PASSWD_des = "password" ROOT_PASSWD_md5 = "second_password" then the system would set the root password to "second_password" and encrypt it using the MD5 algorithm. We may want a QA warning if multiple ROOT_PASSWD declarations are found so the user knows that the root password may not be what they expect. 6. ROOT_PASSWD cannot be appended. For example: ROOT_PASSWD = "pass" ROOT_PASSWD += "word" results in an error. 7. Add the ROOT_PASSWD variable to the Yocto Project manual and a few examples of usage. I'm not sure if other encryption methods would be necessary. Busybox supports only DES and MD5, but I know other password managers support SHA256 and SHA512. It would depend on what demand people had for more options. 40124 4 lpapp 2014-01-31 00:50:11 +0000 Yes, that is more or less inline with what I thought, too. Although, I would make it possible to load the root password from file, e.g. ROOT_PASSWD_file = /path/to/my/password/file. The question is: would anyone be willing to implement it any soon? 76006 5 maciej.pijanowski 2017-08-19 10:57:53 +0000 Hello I'm looking for some unassigned bugs to try start contributing and this looks reasonably to do. Do you think above feature description is up to date? Any hints where this should be implemented (new bbclass, existing class, somewhere else?). Regards 84502 6 richard.purdie 2019-07-25 15:13:09 +0000 I believe its possible to do this already using image post processing commands, we should document those better and give an example of doing this. The details will vary case to case which is why no one default will work in general. 91464 7 Qi.Chen 2021-09-17 01:30:46 +0000 This could be achieved by using extrausers. There's no need to use another ROOT_PASSWD feature. Besides, as the clear password support has been removed from oe-core, the ROOT_PASSWD is also not appropriate any more.