Bug 2093381
| Summary: | Changing password to an user using yppasswd fails | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Daniel Filho <dcamilof> |
| Component: | yp-tools | Assignee: | Ondřej Sloup <osloup> |
| Status: | CLOSED ERRATA | QA Contact: | Vaclav Danek <vdanek> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.5 | CC: | databases-maint, fjanus, hhorak, kwalker, mmuzila, vdanek |
| Target Milestone: | rc | Keywords: | TestCaseProvided, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | yp-tools-4.2.3-2.el8 | Doc Type: | Bug Fix |
| Doc Text: |
Cause: If a user has an exclamation mark (!) or possibly star (*) flag in their hashed password in /etc/shadow, the yppasswd will segfault. Those symbols are not the actual hashed passwords of the user but rather flags of the account. See example:
```
$ ypcat passwd
fedora:!!:1000:1000:fedora cld:/home/fedora:/bin/bash
```
Consequence:
This result in a segmentation fault when the crypt() function in verifypassword() in v4.2.3/yp-tools-4.2.3/src/yppasswd.c receives previous password (salt) as a !! (or *) which is undefined behaviour, and the crypt function returns NULL. The two exclamation marks symbolize a locked account (an account with no initialized password) and a star (a locked account).
```
Changing the NIS password for fedora on XYZ.
Please enter new password:
Segmentation fault (core dumped)
```
Fix:
Since the yppasswd does not have implemented this use case and it would be too difficult to do it now, it is proposed to just exit with an explanation of what happened.
The OpenSUSE is using `--enable-call-passwd` while compiling, which deprecates the yppasswd completely, but that is not a good idea in our case due to backward compatibility. More here: https://www.suse.com/support/kb/doc/?id=000017269
Result:
The patch for adding the check for the flag is added. When the program sees that there is a `!` or `*`, which should not ever happen in a generated hash that is accepted by the crypt function, it will inform the user and close the program.
Workaround:
The user can use passwd tool to change the account, unlock it or set an initial password. This feature is not implemented in yppasswd and will not be implemented by upstream as they deprecated the tool and replaced it with passwd.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-05-16 08:26:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Deadline: | 2022-10-17 | ||
|
Comment 2
Ondřej Sloup
2022-07-04 11:12:15 UTC
The segmentation fault occurs when the `crypt()` function in `verifypassword()` in `yp-tools/v4.2.3/yp-tools-4.2.3/src/yppasswd.c` receives previous password (salt) as a `!!` which is undefined behavior and the crypt function returns NULL. The two exclamation marks symbolize a locked account (account with no initialized password), as explained in https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/4/html/system_administration_guide/s2-redhat-config-users-process. I added a patch which checks this behaviour and informs the user. Usually, the passwords should be set, and therefore there shouldn't be any `!` or `!!`. The patch will be listed in the pull request below. There are two possibilities of how the issue can be fixed: 1. Detect the `!` in /etc/shadow, inform the user and exit the script without password change. 2. Let the user set the password if `!` is detected. This solution brings potential problems with validating users and changing unset root passwords. Need to be discussed with upstream. Current patch to solve the issue is here: https://src.fedoraproject.org/fork/osloup/rpms/yp-tools/blob/rawhide/f/yp-tools-4.2.3-yppasswd-fault.patch Created ticket https://github.com/thkukuk/yp-tools/issues/9 The same issue occurs on Fedora 34, RHEL 8.2 and 8.4 with the yppasswd (yp-tools) 4.2.3. After a conversation on GitHub created a pull request with the fix. https://src.fedoraproject.org/rpms/yp-tools/pull-request/2. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (yp-tools bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2773 |