cPanel & WHM Version 94 has been released, and brings a slew of great updates. Take a look at what is included, and then upgrade today!
This object is in archive! 

Change Date Field in Shadow Files When Email Password Changes

Autumn G. Van Kirk shared this idea 7 years ago
Open Discussion

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:

  1. root@dev [~]# cat ~user/etc/domain.tld/shadow

    test:$1$somehash$A4We.WXbVPvq7v2zo4vZy/:15749::::::

After password change:


  1. 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:

  1. root@dev [~]# grep user /etc/shadow

    user:$1$somehash$mWbT6xBIyFf3rbatXyyJA0:15748:0:99999:7:::

After password change:

  1. 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

Comments (3)

photo
2

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.

photo
1

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.

photo
2

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.

Leave a Comment
 
Attach a file