RFC behavior when shadow passwd file is missing

[Tito]

Hi to all, hi Denis,
I noticed that in busybox we adopt different behavior when the shadow passwd file is missing:

in addgroup:

	file = fopen_or_warn(bb_path_gshadow_file, "a");

in adduser: 

	file = xfopen(bb_path_shadow_file, "a");

in deluser:

	passwd = fopen_or_warn(filename, "r");  

in login, su, vlock (via correct_passwd in libbb):

#if ENABLE_FEATURE_SHADOWPASSWDS
	if (LONE_CHAR(pw->pw_passwd, 'x') || LONE_CHAR(pw->pw_passwd, '*')) {
		if (getspnam_r(pw->pw_name, &spw, buffer, sizeof(buffer), &result))
			bb_error_msg("no valid shadow password, checking ordinary one");

in passwd:

#if ENABLE_FEATURE_SHADOWPASSWDS
	if (getspnam_r(pw->pw_name, &spw, buffer, sizeof(buffer), &result)) {
		/* LOGMODE_BOTH */
		bb_error_msg("no record of %s in %s, using %s",
				name, bb_path_shadow_file,
				bb_path_passwd_file);

in sulogin:

#if ENABLE_FEATURE_SHADOWPASSWDS
	if (getspnam_r(pwd->pw_name, &spw, buffer, sizeof(buffer), &result)) {
		goto auth_error;
	}

snip

auth_error:
	bb_error_msg_and_die("no password entry for 'root'");

so 7 applets just emit a warning and use /etc/passwd instead, while 2 applets
(adduser and sulogin)  error out and die.
Maybe sulogin is a special case as we do not implement the -e  switch:

FALLBACK METHODS
       sulogin  checks  the root password using the standard method (getpwnam)
       first.  Then, if the -e option was specified,  sulogin  examines  these
       files directly to find the root password:

       /etc/passwd,
       /etc/shadow (if present)

       If  they  are  damaged  or nonexistent, sulogin will start a root shell
       without asking for a password. Only use the -e option if you  are  sure
       the console is physically protected against unauthorized access.


but probably adduser could adopt the same strategy as addgroup:

file = fopen_or_warn(bb_path_gshadow_file, "a");


Thoughts?


Ciao,
Tito