Dovecot Authentication
So....
How is one able to log into an email account when said account's shadow file (/home/%user%/etc/%domain%/shadow) is renamed and no longer present?
I've done the:
/usr/bin/doveadm auth cache flush
And the account still shows up when I do a lookup:
/usr/bin/doveadm auth lookup %email%@%account%
Pulling hairs out at the moment
-
Do you have a recent backup you can recover the shadow file from ? 0 -
Sorry, in my haste I may have left out some details. I've still got the shadow file. My point is, even if I rename the shadow file: mv /home/%user%/etc/%domain%/shadow /home/%user%/etc/%domain%/shadow.old and /usr/bin/doveadm auth cache flush The user email user is still able to log in. The login information appears to be being cached some where or maybe I've overlooked something. I had some other errands I had to do and it was just frustrating me that I couldn't explain how that is working. Maybe I missed something, I'll look at it a bit more in-depth now. But I still don't see how it's possible. Is there another cache that needs to be flushed? 0 -
Do you have /home/%user%/etc/%domain%/@pwcache ? That folder looks like it has files containing an encrypted string that could be a cached password for each user and email account 0 -
This actually stems from a larger issue, which probably needs to be it's own thread an issue. But you can suspend a resold account. The reseller can log into the suspended account's cPanel using their reseller password overwrite (if you have that enabled on your server, which we do, perhaps maybe we shouldn't? ... that's a bit beyond the scope here) Change the password to one of the web hosting account's email accounts. And then the email account in question is accessible again with the new password. That would appear to be an oversight some where. Perhaps the reseller shouldn't be able to log into resold accounts with the reseller password overwrite? Or perhaps email account passwords shouldn't be changeable when a web hosting account is suspended? That's what originally set up this issue. I thought, "how is this guy logging into an email account under a web hosting account that I suspended?" Then I tried renaming his shadow file and he's still able to log in. I still don't have an answer to that riddle. 0 -
Do you have /home/%user%/etc/%domain%/@pwcache ? That folder looks like it has files containing an encrypted string that could be a cached password for each user and email account
Ah! That looks to be it. Thanks! Still not entirely sure how this works, but when I rename the @pwcache folder and do am auth cache flush, with the shadow file missing, that seems to resolve this. But when you suspend an account, the shadow file just gets *LOCKED* and the @pwcache directory appears to stay present, and logins do not work. So I'm assuming that authentication will first try to validate a password against the shadow file, and if the shadow file isn't present, it attempts to use the @pwcache entry. This is typically fine, because if there is no reseller then the account can't log into their own cPanel account when it's suspended to change any of the passwords anyway. I suppose the bigger issue now becomes why the password for an email account on a suspended account is being allowed to be changed.0 -
I suppose the bigger issue now becomes why the password for an email account on a suspended account is being allowed to be changed.
The email user isn't able to log in to the account to even change the password, do you mean the reseller can change the email user's password? I can see just cause for wanting to be able to make these modifications as a reseller or root user.0 -
Regarding this particular issue - @rpvw was able to lead me to the resolution here - the existence of the /home/%user%/etc/%domain%/@pwcache cache file.
I did see that and thanks @rpvw (not Shirley though) - I have my own opinions on the necessity for this but I would like to see what becomes of it in the other thread.(perhaps this response needs to be moved to the other thread? I was trying to keep the issues separated)
You're fine I do see that Michael has that thread and I believe is investigating to prepare a reply to you for that - I'd like to watch there to see where that one goes.0 -
and a reseller should also be excluded if the Prevent resellers from unsuspending checkbox was selected when the account was suspended.
This was indeed the case. Locking the suspension just creates an additional /var/cpanel/suspended/user.lock file for the suspended account. And that was present. The reseller was still able to log into the reseller account - with what best I could tell was their reseller overwrite. Additionally, what appears to happen. When an account (entire cPanel account) is suspended the shadow files for the email accounts on all the domains for that account are changed: localpart:*LOCKED*hash:number::::::*LOCKED* The addition of *LOCKED* in the password hash section effectively disables the user from being able to check or authenticate that email account. When the root/reseller overwrite is used and the individual changes the password, the shadow file gets changed to: localpart:newhash:number::::::*LOCKED* So the password hash section gets rewritten with a new hash. The term *LOCKED* still exists at the end of the line, indicating that it was locked at one time. This to me just spells that this is an unintended consequence of allowing root/reseller overwrite to be used to log into suspended accounts. I don't really know what the solution is I'm kind of of the thinking that if an account is suspended - regardless if the reseller/root unsuspension lock file is present or not - nobody should be able to log into the cPanel of the account. I'm not sure what the point of being able to log into a suspended account would be. But I am also open to hearing what everyone else thinks. I thought about creating a hook to immute the shadow file. But then I would have to create another hook to remove the immute flag before unsuspension and account deletions. And that seems like a hassle. Keep in mind, I suspect that this also carries over to database user passwords. Those users are also locked in the database server on suspension, but I'm guessing a root/reseller overwrite login will be able to change these as well - although to what end, that's not immediately clear to me - it's not like the email thing. The reseller could also log in, and remove offending files after suspension resulting in "What malicious files?" There's really just cause for concern that anybody is even being allowed to log into a suspended account. But like I said, I'm willing to hear what others have to say.0
Please sign in to leave a comment.
Comments
10 comments