LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   User without a password? (https://www.linuxquestions.org/questions/slackware-14/user-without-a-password-4175675708/)

felipeperona 05-22-2020 08:40 AM

User without a password?
 
Hello,

I have just finished installing the -current branch of Slackware64 in my PC. It was not an update, I formatted the disk and did a clean install.

I wanted to create my users and I realised that now you need to set an non-empty password for yours users.

I used to have my login with an empty password (just push enter when I was asked for my password) and I would like to keep it in that way. I suppose it is related with the change to PAM. Is there any way to change the configuration and allows empty passwords for users?

Thanks!

Alien Bob 05-22-2020 09:10 AM

Quote:

Originally Posted by felipeperona (Post 6126039)
Hello,

I have just finished installing the -current branch of Slackware64 in my PC. It was not an update, I formatted the disk and did a clean install.

I wanted to create my users and I realised that now you need to set an non-empty password for yours users.

I used to have my login with an empty password (just push enter when I was asked for my password) and I would like to keep it in that way. I suppose it is related with the change to PAM. Is there any way to change the configuration and allows empty passwords for users?

Thanks!

The system-auth module in Slackware's PAM has these two lines, for password validation and for authentication
Code:

/etc/pam.d/system-auth:auth        sufficient    pam_unix.so likeauth nullok
/etc/pam.d/system-auth:password    sufficient    pam_unix.so nullok sha512 shadow minlen=6 try_first_pass use_authtok

And the explanation comes from another source (at Redhat):

The "nullok" parameter allows for a login with an empty password, but there are some caveats as to what is an "empty password".
Having "nullok" works only if the password field in the /etc/shadow file (that is the second colon-separated field) is empty.
What usually happens instead is that the password field in /etc/shadow contains either '!!' or '*' to indicate that the account is locked. This would then be replaced with a hashed password, when root sets a password for the user.
The password field will only be actually empty only when root removes the password:
Code:

passwd -d <user>
or when root unlocks an account that has no password.

felipeperona 05-23-2020 06:00 AM

Yes, indeed that was the problem. I tried a couple of options in the lines you pointed out, but the result was always the same, the user remains locked.

So I took the quick solution:

Code:

passwd -d <user>
It is ok in that way for now,

Thanks!

abga 05-26-2020 07:40 PM

Quote:

Originally Posted by Alien Bob (Post 6126043)
The password field will only be actually empty only when root removes the password:
Code:

passwd -d <user>
or when root unlocks an account that has no password.

Could this get included in the /usr/sbin/adduser script as an automation for an empty password (after pressing multiple times Enter when the password is asked)?

bassmadrigal 05-26-2020 08:26 PM

Quote:

Originally Posted by abga (Post 6127697)
Could this get included in the /usr/sbin/adduser script as an automation for an empty password (after pressing multiple times Enter when the password is asked)?

passwd itself is invoked directly in the script, so either passwd would need to be modified or you'd need to check and see if passwd passes a specific exit code if a blank password is specified and add a catch into the adduser script.

abga 05-26-2020 08:39 PM

Quote:

Originally Posted by bassmadrigal (Post 6127718)
passwd itself is invoked directly in the script, so either passwd would need to be modified or you'd need to check and see if passwd passes a specific exit code if a blank password is specified and add a catch into the adduser script.

I wouldn't care about passwd in the helper script /usr/sbin/adduser, but focus on the interaction with the user, its sole purpose for being provided in the first place.
Now with the PAM-ification it wouldn't let you provide an empty password (pressing Enter repeatedly) and you have to either enter one or just kill it:
Quote:

New password:
BAD PASSWORD: No password supplied
Retype new password:
No password supplied
passwd: Authentication token manipulation error
passwd: password unchanged
- Warning: An error occured while setting the password for
this account. Please try again.
New password: Terminated

bassmadrigal 05-26-2020 09:03 PM

Unless the adduser script has changed in -current, this looks to be an issue with passwd directly since the script just calls passwd and if it doesn't complete the process properly (an exit code other than 0), then it is supposed to exit the adduser script after displaying a warning.

Code:

# Set a password
$passwd "$LOGIN"
if [ $? -gt 0 ]; then
  echo "* WARNING: An error occured while setting the password for"
  echo "          this account.  Please manually investigate this *"
  exit 1
fi

Since your error seems to be different than this, it looks to be something built into the passwd binary. If there's no flags to adjust this behavior, then adduser will either need to be changed to reflect this or adduser just won't support adding accounts with blank passwords.

I suppose it is possible for the script to ask if a user is expected to have a blank passwd and then either issue passwd -d on that user or exit and let root do it themselves after. If they answer that the user is expected to have the passwd, then they could run passwd normally. There doesn't seem to be a way to allow scripting of changing the passwd (unless -current's passwd binary is different than 14.2's).

abga 05-26-2020 09:37 PM

The output is from a recently updated (today) Slackware ARM -current. And my proposal (question) was to fix the adduser script, make it behave like before the PAM-ification. In this PAM context now, just use a condition to catch if the user is pressing Enter multiple times at the Password question and don't call & pass anything to passwd yet, but use "passwd -d <user>" in this case.
Slackware 14.2 - "unPAM-ified" classic behavior of the adduser script.
Code:

Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and numbers.
New password:
Bad password: too short.
Warning: weak password (enter it again to use it anyway).
New password:
Re-enter new password:
passwd: password changed.


Account setup complete.

Again, it's a question/proposal/wonder ... whatever. I just noticed this new behavior of the adduser script after PAM-ifying the -current on ARM and recalled that there was a recent discussion in the main Slackware forum (this thread).

bassmadrigal 05-26-2020 10:34 PM

I forgot that Pat changed adduser about a year back. When he did, he introduced the possibility of an infinite loop for chfn and passwd in the adduser script. I had suggested an alternative, but it was never taken (maybe missed or felt it wasn't necessary at the time).

Code:

# Set the finger information
$chfn "$LOGIN"
while [ $? -gt 0 ]; do
  echo "- Warning: an error occurred while setting finger information."
  answer=$(get_input "          Would you like to try again? (Y/n) ")"
  if [ "$(echo $answer | grep -i "n")" ]; then
    break
  fi
  $chfn "$LOGIN"
done

# Set a password
$passwd "$LOGIN"
while [ $? -gt 0 ]; do
  echo "- Warning: An error occurred while setting the password for"
  answer=$(get_input "          this account. Would you like to try again? (Y/n) ")"
  if [ "$(echo $answer | grep -i "n")" ]; then
    break
  fi
  $passwd "$LOGIN"
done

I'll throw this into the Requests for -current thread to see if Pat is interested in adjusting adduser.

abga 05-26-2020 11:13 PM

Well, thing is, modifying adduser is less invasive (and cleaner) than goofing around with the upstream passwd and the whole PAM orchestration.

bassmadrigal 05-26-2020 11:38 PM

Quote:

Originally Posted by abga (Post 6127760)
Well, thing is, modifying adduser is less invasive (and cleaner) than goofing around with the upstream passwd and the whole PAM orchestration.

I wasn't really suggesting modifying upstream, but instead the adduser portion adding the option. I don't know if it'd be possible to catch the user hitting enter multiple times since the prompt is provided by passwd itself.

I suppose there could also be an option added to allow someone to delete the "password" if passwd isn't ran successfully.

abga 05-26-2020 11:40 PM

Just had a closer look at the updated (-current) adduser script and learned that it actually calls passwd directly and that passwd doesn't have a non-interactive mode anymore. Thus, no way to read user input and stop if it presses enter, at least not with passwd. chpasswd could be an option.
https://stackoverflow.com/questions/...a-shell-script

Well, forget it! :)


All times are GMT -5. The time now is 01:22 AM.