1

Topic: Users can't change passwords from RoundCube

==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.6.2
- Deployed with iRedMail Easy or the downloadable installer? Installer
- Linux/BSD distribution name and version: Rocky 9.1
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MariaDB
- Web server (Apache or Nginx): Apache was deprecated long ago!
- Manage mail accounts with iRedAdmin-Pro? No
- Error message:
Could not save new password
Encryption function missing

====
When users try to change password from within RoundCube, all they get is popup message in the lower right saying "Could not save new password   Encryption function missing".

Sorry if this is a duplicate of some other post, the forum search seems to be broken at the moment (see my other post re this).

Thanks in advance for all help,
Paul

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 (edited by evenmoreconfused 2023-04-17 02:07:05)

Re: Users can't change passwords from RoundCube

I see from https://forum.iredmail.org/topic18494-r … issing.htm that it is caused by dovecot (which iRedMail uses to generate password hashes) being unable to access /etc/pki/tls/private/iRedMail.key (the post is about Debian 11, but I have the same issue with Rocky 9.1).

I've tested manually with doveadm pw in user mode and confirmed that non-root users cannot access the file.

What I can't understand (yet) is what to do about it. I am loath to simply open up access to the file for web users. Or is that safe to do?

3 (edited by evenmoreconfused 2023-04-17 10:41:47)

Re: Users can't change passwords from RoundCube

The kind folks at LetsEncrypt have helped clarify that this is a fairly fundamental problem:

doveadm pw will always fail now unless either:
A. it is run as root, or
B. the private key file permissions are compromised

This is because doveadm now parses the entire dovecot configuration, including verifying access to every file specified, regardless of what the subcommand is. Since some of the specified files have root-only access (e.g. private keys), doveadm fails with error 89 unless run as root.

They suggest that unless the Dovecot team fixes doveadm, iRedMail's implementation of RoundCube should be consider a different means to acquire the password hash (how does iRedAdmin get it, I wonder?).

See https://community.letsencrypt.org/t/cha … les/196561

4 (edited by evenmoreconfused 2023-04-18 23:11:22)

Re: Users can't change passwords from RoundCube

I received the following reply when I reported this on the Dovecot mailing list:

This is a bug, but you can workaround it with

ssl=no
!include_try ssl.conf

and put in ssl.conf

ssl=yes
ssl_cert=</path
ssl_key=</peth

or try with 2.3.20

Haven't yet tried Dovecot 2.3.20 to see if the problem's resolved though.

Update: according to the Dovecot change logs, this issue is specifically fixed in 2.3.17. Will test!

5 (edited by evenmoreconfused 2023-04-23 02:10:42)

Re: Users can't change passwords from RoundCube

Update for Posterity:
---------------------------
1. It turns out that this is caused by a known bug in dovecot that exists in (dovecot) versions 2.3.11 thru .16. It is fixed in later versions -- the current stable version is 2.3.20 -- but some distros (apparently Redhat / Rocky / Alma 9.1 and others) include by default one of the buggy versions.

Brief summary of the bug: iRedMail uses a utility function built into dovecot to calculate password hashes. This function (doveadm) was broken so that it always opens every file listed in the main dovecot config, even when unnecessary for its current task. When using certbot to manage keys, one file listed is the private key, which is (quite sensibly) not available to general tasks.

2. There are several messy things one could do to get a different version of dovecot in a "factory version" of one's distro, including:
- getting the distro manager to apply just the needed patch to the "factory" distro ("backporting");
- incorporating dovecot's own repository (https://repo.dovecot.org) and installing the current dovecot from there; or
- using one of the less mainstream repositories for your distro (e.g. ghettoforge) to install the newer version of dovecot.

3. Being reluctant to start mixing and matching distro packages (not because I'm worried it won't work now, but I worry future OS updates may get confused), I am currently taking a different messy work-around:
- temporarily change the access on /etc/letsencrypt/archive/<domain>/privkey1.pem from 600 to 644, let the user make the password change, and then reset the access to 600.

This happens to be acceptable in our small environment, but it may not be to many. However, I cannot recommend making the private key permanently generally accessible.

Paul

6

Re: Users can't change passwords from RoundCube

Since Rocky is based on RHEL, you can do this:

http://ghettoforge.org/index.php/Usage

You can upgrade to 2.3.19 without doing dirty fixes

7

Re: Users can't change passwords from RoundCube

Just a note to say that the issue is unresolved in Rocky 9.2 (and presumably RedHat 9.2 and Alma 9.2) as 9.2 only updates Dovecot to 2.3.16 (whereas the fix is in .17).

So it's keep waiting or use ghettoforge as above.