Change Date Field in Shadow Files When Email Password Changes
Greetings,
As of WHM 11.38.2.2 there is an issue wherein changing an email password does not change the 'last changed' field (field 3 where : is the delimiter) of the shadow file, which represents the number of days since the Unix epoch:
Before password change:
- root@dev [~]# cat ~user/etc/domain.tld/shadow
test:$1$somehash$A4We.WXbVPvq7v2zo4vZy/:15749::::::
After password change:
- root@dev [~]# cat ~user/etc/domain.tld/shadow
test:$1$somehash$LXAw.Zw.qCdmgkueBdGW90:15749::::::
This behavior works as expected when the cPanel account password is changed:
Before password change:
- root@dev [~]# grep user /etc/shadow
user:$1$somehash$mWbT6xBIyFf3rbatXyyJA0:15748:0:99999:7:::
After password change:
- root@dev [~]# grep user /etc/shadow
user:$1$somehash$MWIf.J1pSvcm0ed4YYg9O0:15938:0:99999:7:::
Ostensibly this seems to happen because the userland passwd utility is called by WHM when a password change is requested.
This field provides valuable insight to systems administrators when investigating abuse complaints regarding email addresses on a given system, and should behave comparably to the system shadow file.
In summation, this request is to ensure that the email password change function of WHM changes the 'last change' field of the corresponding shadow file.
Regards,
Adam G. Van Kirk
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
To add a bit of clarification, despite the "As of 11.38.2.2" verbiage in the original post, this is not new or regressed behavior. cPanel & WHM has always effected mailbox password changes by targeting and modifying the hash in the shadow file explicitly versus rewriting the entire shadow line each time. This is intentional per the existing logic.
Therefore this request is indeed for a brand new feature and not a bug/revert of prior behavior.
To add a bit of clarification, despite the "As of 11.38.2.2" verbiage in the original post, this is not new or regressed behavior. cPanel & WHM has always effected mailbox password changes by targeting and modifying the hash in the shadow file explicitly versus rewriting the entire shadow line each time. This is intentional per the existing logic.
Therefore this request is indeed for a brand new feature and not a bug/revert of prior behavior.
I can agree that this appears to have been the behavior of cPanel for as long as I can recall. Therefore in reference to cPanel it is a new feature, but I would hesitate to think of it as entirely a new feature as this behavior is inconsistent with the de facto structure of the Shadow file.
Red Hat defines the structure of the Shadow file in the following documents:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Introduction_to_System_Administration/s1-acctsgrps-rhlspec.html
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Introduction_To_System_Administration/s3-acctsgrps-shadow.html
One would expect an application to behave consistently within itself, and to comply with the standards of its parent operating system - neither of which cPanel does in this case.
I can agree that this appears to have been the behavior of cPanel for as long as I can recall. Therefore in reference to cPanel it is a new feature, but I would hesitate to think of it as entirely a new feature as this behavior is inconsistent with the de facto structure of the Shadow file.
Red Hat defines the structure of the Shadow file in the following documents:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Introduction_to_System_Administration/s1-acctsgrps-rhlspec.html
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Introduction_To_System_Administration/s3-acctsgrps-shadow.html
One would expect an application to behave consistently within itself, and to comply with the standards of its parent operating system - neither of which cPanel does in this case.
Agreed, the feature request does make sense and is logical. I simply wanted to document the nature of it, as regressed behavior would be considered a bug and need to be filed by us accordingly as such if that was the case (I didn't want any other staff thumbing through features to panic and wonder if we broke existing functionality for this situation).
I definitely agree with you that this feature request is useful and logical. It's a bit unintuitive for us to mock up a shadow file and then not be consistent with how shadow files are built and maintained within a *nix system.
Agreed, the feature request does make sense and is logical. I simply wanted to document the nature of it, as regressed behavior would be considered a bug and need to be filed by us accordingly as such if that was the case (I didn't want any other staff thumbing through features to panic and wonder if we broke existing functionality for this situation).
I definitely agree with you that this feature request is useful and logical. It's a bit unintuitive for us to mock up a shadow file and then not be consistent with how shadow files are built and maintained within a *nix system.
Replies have been locked on this page!