Bug 6938 - mkuser script generates wrong password for new user in target/etc/shadow
Summary: mkuser script generates wrong password for new user in target/etc/shadow
Status: RESOLVED INVALID
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2013.11
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-27 10:49 UTC by Pavel Kucera
Modified: 2014-02-27 13:01 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Kucera 2014-02-27 10:49:38 UTC
I've modified my mkusers script from buildroot-2013.11/support/scripts to generate correct passwords for manually added users from custom packages. I've renamed files, so the changes are clear.

diff -u mkusers_2013.11 mkusers_2013.11_modified 
--- mkusers_2013.11	2014-02-27 11:06:38.000000000 +0100
+++ mkusers_2013.11_modified	2014-02-27 11:05:15.000000000 +0100
@@ -261,7 +261,7 @@
 
 #----------------------------------------------------------------------------
 # Encode a password
-encode_password() {
+encode_passwd() {
     local passwd="${1}"
 
     mkpasswd -m "${PASSWD_METHOD}" "${passwd}"
@@ -313,7 +313,7 @@
             _passwd="$( encode_passwd "${passwd#=}" )"
             ;;
         *)
-            _passwd="${passwd}"
+            _passwd="$( encode_passwd "${passwd}" )"
             ;;
     esac
Comment 1 Thomas De Schampheleire 2014-02-27 12:17:23 UTC
Please describe in more detail the problems you are experiencing, otherwise we cannot help you.

- What is the problem with the passwords generated from the script?
- How are you using the script?
- Which password method have you configured (BR2_TARGET_GENERIC_PASSWD_METHOD)
- If you are using SHA256 or SHA512, are you sure that the busybox application (assuming you are using it) is configured with the following option: CONFIG_USE_BB_CRYPT_SHA ?
Comment 2 Pavel Kucera 2014-02-27 12:32:52 UTC
OK, I'll describe it in more verbose way, but the few line diff I've posted before does the trick.

1) What is the problem with generated password
Original mkusers generates next line in target/etc/shadow
nguser:nguser:::::::

Modified generates this line which works good
nguser:$1$Fmk.0Eps$q/41A9m1kv7ECQcV6QJCl0:::::::

2) How am I using script
I'm using script by calling 'make' in buildroot_2013.11 directory.
I added custom package with this line in its makefile (newg.mk)
NEWG_USERS = nguser -1 nguser -1 nguser /home/nguser /bin/sh video,dialout Ng user

3) Which password method
md5

4)
NA

I've found, that in mkusers there is a function encode_password, which is never called and there is call of encode_passwd which isn't present, so it's just a typo. And later in mkusers there is a switch with case '*)' which doesn't call encode password and provide password to be placed in target/etc/shadow in plain text, as well as the problem reported in paragraph 1)
Comment 3 Thomas De Schampheleire 2014-02-27 12:50:03 UTC
Thanks for the additional information.
The problem is not a bug, but a misunderstanding on your part, I think. The password can be provided in three ways, as stated by the manual on this topic:

http://buildroot.uclibc.org/downloads/manual/manual.html#makeuser-syntax
-----
password is the crypt(3)-encoded password. If prefixed with !, then login is disabled. If prefixed with =, then it is interpreted as clear-text, and will be crypt-encoded (using MD5). If prefixed with !=, then the password will be crypt-encoded (using MD5) and login will be disabled. If set to *, then login is not allowed. 
-----

So if you expect to provide a clear-text password that is encoded by the mkusers script, you should prefix it with '=', so:

NEWG_USERS = nguser -1 nguser -1 =nguser /home/nguser /bin/sh video,dialout Ng
user

As I believe the problem is solved if you add the '=', I will close this bug. Please reopen if you still face problems.
Comment 4 Pavel Kucera 2014-02-27 13:01:05 UTC
I'm OK with closing this bug. Looked in a master tree and the typo is fixed here, so there is no problem anymore. Thank you to guide me to correct usage.