Postfix: newaliases fails at postfix service startup due to aliases.db permission problems

Question

I recently started migrating my mail server to systemd.

I have an alias hash map:

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases

When starting the service:

systemctl restart postfix

newalias and postalias complain about the permissions of my aliases.db whatever permissions I set:

● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
     Active: active (running) since Wed 2020-07-22 00:36:08 CEST; 22ms ago
    Process: 299515 ExecStartPre=/usr/bin/newaliases (code=exited, status=1/FAILURE)
    Process: 299518 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
   Main PID: 299596 (master)
        CPU: 721ms
     CGroup: /system.slice/postfix.service
             ├─299596 /usr/libexec/postfix/master -w
             ├─299597 pickup -l -t unix -u
             └─299598 qmgr -l -t unix -u

jul 22 00:36:07 rulakir systemd[1]: Starting Postfix Mail Transport Agent...
jul 22 00:36:07 rulakir newaliases[299515]: postalias: fatal: open /etc/postfix/aliases.db: Read-only file system
jul 22 00:36:07 rulakir postfix/postalias[299515]: fatal: open /etc/postfix/aliases.db: Read-only file system
jul 22 00:36:08 rulakir postfix/postfix-script[299582]: warning: group or other writable: /etc/postfix/./aliases.db
jul 22 00:36:08 rulakir postfix/postfix-script[299594]: starting the Postfix mail system
jul 22 00:36:08 rulakir postfix/master[299596]: daemon started -- version 3.5.1, configuration /etc/postfix
jul 22 00:36:08 rulakir systemd[1]: Started Postfix Mail Transport Agent.

It complains that it read only, but if I change group or owner to postfix it complains that it should be owned by root and/or that it has write permissions. What permissions should I give to aliases and aliases.db?

The permissions are not the problem, the read only file system is the problem! Check your logs to find out why the filesystem is read only. — Michael Hampton, Jul 21 '20 at 23:07
The file system is not read-only, everything resides on my root partition which is mounted rw and working properly. Or is postfix somehow sandboxed in systemd? — Jens Björnhager, Jul 22 '20 at 00:23
OK, then why does it complain that your filesystem is read only? — Michael Hampton, Jul 22 '20 at 00:25
To clarify: newaliases and postalias seem to work outside of service. — Jens Björnhager, Jul 22 '20 at 00:26
Yes, that is a good question. Are you sure it's not complaining about the file specifically? — Jens Björnhager, Jul 22 '20 at 00:27
Is this a Debian-based system? It looks like it might be. That could be part of the issue. Debian based distros do a lot of strange things. — Michael Hampton, Jul 22 '20 at 00:27
No I don't think it's based on Debian, Gentoo is its own thing. — Jens Björnhager, Jul 22 '20 at 00:35
Gentoo? OK, that's an unusual choice. I'm not sure how much help most of us can be with that. — Michael Hampton, Jul 22 '20 at 00:37
Based on the Gentoo [systemd service](https://gitweb.gentoo.org/repo/gentoo.git/tree/mail-mta/postfix/files/postfix.service), I'm guessing one of the hardening options is messing with `newaliases`. Are your running `~amd64` or is this a stable system? — Ginnungagap, Jul 22 '20 at 11:47
To be fair, based on systemd's documentations, the restrictions should work, I'd suggest disabling them to validate that's the issue and filing a bug on bugs.gentoo.org if it is. — Ginnungagap, Jul 22 '20 at 11:54
Stable system. Only running ~amd64 on smartmontools. What restrictions are those? I'm not running hardened or something like that. I also ran fsck. It seemed to fix something, but still same problem. — Jens Björnhager, Jul 22 '20 at 13:08
Wow, so it IS sandboxed! **ProtectSystem "If set to "full", the /etc directory is mounted read-only, too."** — Jens Björnhager, Jul 22 '20 at 13:19
@Ginnungagap: Not tested yet, but if you want to write an answer, I can accept it. — Jens Björnhager, Jul 22 '20 at 13:19
I'll write a more complete one in a bit, I'm on mobile right now, but the ReadWritePaths should enable writing to the aliases only it seems to have been moved to `/etc/mail` instead of `/etc/postfix` — Ginnungagap, Jul 22 '20 at 13:58
No need to change the unit, I moved the databases out of `/etc/postfix` to `/var/lib/postfix` and everything is happy. — Jens Björnhager, Jul 22 '20 at 14:13

score 1 · Accepted Answer · answered Jul 23 '20 at 06:49

The Gentoo mail-mta/postfix package's systemd service unit includes hardening options by default which do indeed sandbox the service. Specifically:

ProtectSystem=full
ReadWritePaths=-/etc/mail/aliases.db

Despite the additional sandboxing, the /etc/mail/aliases.db file should be writable thanks to the ReadWritePaths. From the systemd.exec man page:

ProtectSystem=

Takes a boolean argument or the special values "full" or "strict". <...> If set to "full", the /etc directory is mounted read-only, too.

ReadWritePaths=

Paths listed in ReadWritePaths= are accessible from within the namespace with the same access modes as from outside of it.

Paths in ReadWritePaths=, ReadOnlyPaths= and InaccessiblePaths= may be prefixed with "-", in which case they will be ignored when they do not exist.

Based on the latest stable mail-mta/postfix ebuild (3.5.1) as of this writing, src_prepare includes sed -i -e "/^#define ALIAS_DB_MAP/s|:/etc/aliases|:/etc/mail/aliases|" to set the default location of the alias map at the appropriate location. Yet from your logs, yours seem to point to /etc/postfix/aliases.db. I'd suggest leaving the default of /etc/mail/aliases.db or overriding the ReadWritePaths using systemctl edit postfix.service appropriately.

As the entire `/etc` was write protected `by default, I put them in `/var/lib/postfix` instead and it is happy. — Jens Björnhager, Jul 23 '20 at 11:51

Postfix: newaliases fails at postfix service startup due to aliases.db permission problems

1 Answers1