Score:1

How can I safely stop postfix being picky about group permissions of sqlite database?

de flag

Background

I set up an example postfix server using sqlite to store the aliases and mailbox details, (so that they could be updated live and have a single source of truth being the database.)

I have the parts of postfix running chroot where possible for security, so the database (mail.sqlite) is in /var/lib/postfix/ (That all works.)

The required functionality

I wrote a web front end to let users add new email addresses. The web front end is running as www-data.

I added www-data to the postfix group so that chmod g+rw /var/lib/postfix/mail.sqlite /var/lib/postfix/ would enable the web front end to update the database.

Email is flowing in and out. The web front end can Create Remote Update Delete aliases. I restart postfix and check the logs:

postfix/postfix-script[26524]: warning: group or other writable: /var/lib/postfix/.
postfix/postfix-script[26525]: warning: group or other writable: /var/lib/postfix/./mail.sqlite

If I chmod g-w /var/lib/postfix/mail.sqlite that makes postfix happy, but removed the ability for my web front end to add new aliases.

I could have a cron script to replace /var/lib/postfix/mail.sqlite with an authoritative /var/www/admin/app/mail.sqlite, but that smells like race condition, or at least is inelegant.

(I wonder why postfix is referring to the database as "/var/lib/postfix/./mail.sqlite" when the config is dbpath = /var/lib/postfix/mail.sqlite?)

The question

How can I give my cgi web front end write access to postfix's database, without running it as postfix and while keeping postfix happy? (I think that I have to solve this before I add in SELinux policies.)

Edit:

I had main.cf with

virtual_mailbox_maps = sqlite:/etc/postfix/sqlite_mailbox.cf
virtual_alias_maps = sqlite:/etc/postfix/sqlite_alias.cf
virtual_mailbox_domains = sqlite:/etc/postfix/sqlite_domains.cf

and have tried proxymap:

virtual_mailbox_maps = proxy:sqlite:/etc/postfix/sqlite_mailbox.cf
virtual_alias_maps = proxy:sqlite:/etc/postfix/sqlite_alias.cf
virtual_mailbox_domains = proxy:sqlite:/etc/postfix/sqlite_domains.cf

Both seem to work equally well for email processing, but after restarting postfix, both still log:

postfix/postfix-script[957]: warning: group or other writable: /var/lib/postfix/.             
postfix/postfix-script[958]: warning: group or other writable: /var/lib/postfix/./mail.sqlite
Nikita Kipriyanov avatar
za flag
Why do you stick with SQLite? Is there any reasoning behind this? MariaDB (MySQL) is cheap and easy way to do the same thing without worrying about file permissions.
de flag
I love MariaDB but this environment is limited and installing a full database is overkill for a simple key:value lookup.
Nikita Kipriyanov avatar
za flag
Then have you tried to use a postfix [proxymap](http://www.postfix.org/proxymap.8.html) service?
de flag
I had not tried proxymap. It looks like that is the best solution. I've tried it but postfix is still warning about group permissions.
Score:2
jo flag

The source of this error is from the script "postfix-script" at this point:

find $queue_directory/. $queue_directory/pid \
    -prune \( -perm -020 -o -perm -002 \) \
    -exec $WARN group or other writable: {} \;
..
find $todo \( -perm -020 -o -perm -002 \) \
    -exec $WARN group or other writable: {} \;
..
find $data_directory/. \( -perm -020 -o -perm -002 \) \
    -exec $WARN group or other writable: {} \;
..

$todo is effectively config_directory, shlib_directory, daemon_directory and meta_directory as a list.

You can run the postconf command to work out what those variables are.

$ postconf queue_directory config_directory daemon_directory meta_directory shlib_directory data_directory
queue_directory = /var/spool/postfix
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
data_directory = /var/lib/postfix

This would seem to suggest, if you keep the the actual sqlite databases outside of those directories, postfix-script will be unawares to check them.

So you could just create something new shared by the web server and the mail server, say - /srv/maildb/ setup the ownerships as per your preferences and get around it like that.

Oh, I would point out you'd probably want to alter your chroot environment to support loading the data in. You could potentially use a hard link but that feels like a hack.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.