vexim 2-master can't create domain physical directory

[Matt Darcy]

running the current master branch version (as of 23/07/2016) on Centos 7.2 with  PHP 5.4 and Maria DB 5.5 I'm having a problem with the creation of the domain directory on the file system.

i've got a non-interactive user account setup for vexim to hold mail data on, with a uid/gid of 600.

I put the domains in $HOME/domains

I've configured variables.php to contain $mailroot = "/home/mailmgr/domains/";

which is owned by uid/gid 600

the permissions on this directory where 770

Evrerytime I tried to create a local domain I got the error

Domain Mail directory /home/mailmgr/domains does not exist, is not a directory or is not accessible.

which I found was linked to this commit

https://github.com/vexim/vexim2/pull/75/files

The domain however was fully accessible to UID/GID 600 - as configured in varaibles.php.

I found a post from Rimas stating he'd had this problem and that it wasn't actually permission related, so I thought I'd do a test to remove doubt, and set /home/mailmgr/domains to 777 just to see what happened.

this time the vexim interface said it created the domain (and it's in the database) and it shows up as created in the web interface.
However there is no directory on the file system.

I've got selinux disabled for testing, so there is nothing stopping this from working.

any input to this situation ?

Thanks,

Matt

[Matt Darcy]

I think I've found this reading an old thread and searching for a few lines of code with my basic php knowledge.
it's because it can't send the welcome mail.

I'm not sure if a.) a welcome mail is a "requirement" and shouldn't block the creation of a domain, this doesn't seem like a good dependency b.) not sure if a welcome mail is really adding any value from a functional point of view.

Maybe look at removing this ? maybe a toggle ?

Matt

[Udera Udera]

The problem is that vexim-scripts run with webserver-permissions that don't provide access to the vmail-storage. In order to create the actual mailbox, a new mail is sent, then exim creates the folder structure in the vmail-storage and delivers the mail.

[Matt Darcy]

so that makes logical sense, and I'd half considered this, but it didn't add up as I was looking at my old pre 2.2.1 system, which I'm partially copying the setup (not direct line for line - but more how it's laid out).

I have the same layout with /home/mailmgr/domains - owned by mailmgr (uid 600/600 again).

However my exim mail server runs as the user exim uid/gid 93/93

so how is exim uid 93 creating the directories in /home/mailmgr/domains which is owned and only writable by uid 600 drwxrwx--- 6 mailmgr mailmanager 4096 2013-03-25 11:32 domains
on my working system ?

[Rimas Kudelis]

Hi Matt,

Exim uses setuid/setgid (or whatever) when delivering e-mails, that's why the owner of the email file is always the user to which it belongs. That's also why it can access directories with access restrictions for group or world.

If you set `$mailroot = "/home/mailmgr/domains/"`, and this directory does not exist, or is not accessible to the web server (e.g. /home/mailmgr/ has 0700 as its mask), you get the error during domain creation. You have two options to get rid of the error: you can either let the web server check for existence of $mailroot (by changing directory masks appropriately), or disable this check in the config file, taking the responsibility to make sure it is valid onto yourself. Like I explained in #71 and #75, the reason why this check exists is to prevent creating domains with invalid configuration (e.g. creating example.org domain with a patch of /var/vmail/example.org, where /var/vmail does not even exist and will not be created by Exim, because /var is only writable by root). Again, this check can be disabled in the config, and it might be the right approach to take in your situation.


The welcome mail is certainly not a requirement, but it's being sent using the standard mail() call AFTER the domain is created, so if creation fails, it fails before that. This message isn't really necessary, but, like Udera wrote, it helps you see whether or not your setup works, because if it does, Exim will create the necessary directory structure when delivering this e-mail to its recipient. If you have created a domain successfully, but don't see its directory a few seconds (or a minute) later, this is a good indication that something is not right, and you should go check Exim logs.

Regards,
Rimas

[Matt Darcy]

Great feedback and information, thank you.

[Matt Darcy]

as I'm putting this setup in place I'm making notes to put a pull request in for some of the documentation to try to get this a little more sanitized and maybe a little more detail in some areas.


From an ideal perspective, what should the permissions on $mailroot actually be to successfully pass the validation checks and be able to create the directory structure without opening up the ability to compromise mail messages post delivery.

We have 3 users here

1.) Webserver user
2.) exim user, which will setuid / setgid to vexim user on delivery.
3.) vexim user

The webserver user needs to be able to read $mailroot to be able to pass the validation checks. so the webserver user either needs to be a member of the vexim users group and put read permissions on group, or it the directory needs world read permissions, but not have world read permissions on the sub-directories so you can't see inside peoples mail directories.

Is this the best way to do it (I can't see a better one) or something better ?

[Rimas Kudelis]

Well, for one, I don't think adding the webserver user to vexim group should be advised. I'd go with setting Read and/or eXecute permissions to satisfy the web server instead. For example, it seems that on Debian systems, /var is 755, and /home/*/ are 755 as well by default. This is enough for the PHP server check to pass successfully.

Or, like I said, you can set $testmailroot to false in variables.php


Looking ahead, it might make sense for us to allow disabling the "Domain Mail directory" field, and always using the default value from the config file instead, which might actually be enough for most installations. We could even have it disabled by default. And with this field disabled, we wouldn't have to run checks to test for the validity of its value, so you could have your mail stored somewhere in a directory with a 700 mask.

Rimas

[Harald bieger]

Hi Matt

The same happens to me , and i was wrong searching  at Webserver or php files.
The webserver didnt create  the dirs and files ,  thats EXIM  

In my case i needed to correct   append driver  to right path.

cheers Harry