[Dovecot] Please help me resolve why mail isn't being delivered to virtual users

[Pascal Volk]

Am 09.01.2008 21:43 schrieb Asheesh Laroia:
> Not in the way I was describing:
> 
> Let's say some person logs on to your Dovecot-based IMAP service and 
> figures out how to take over Dovecot to read and modify arbitrary files on 
> the system.  (Timo, I hope this doesn't happen - but bear with me.)  To be 
> clear, Dovecot's imap handler runs as the UNIX UID associated with the 
> user logging in, not root.
> 
> In the virtual user setup that the thread starter described, the user 
> shares his UNIX UID with the other virtual users on the system.  So he has 
> UNIX permission to read and write other users' mail.

This will be only the case, if you have a poor™ setup.
If the setup is done right, each imap/pop user will have it's on UID.
And therefor each imap/pop process will run with the UID from the user.

,--[ `ps aux | grep imap | head -n 5` ]--
| 70001     5691  0.0  0.0   2676  1416 ?        S    12:45   0:00 imap
| 70002     5693  0.0  0.0   2600  1212 ?        S    12:45   0:00 imap
| 70014     5695  0.0  0.0   2676  1256 ?        S    12:45   0:00 imap
| 70013     5696  0.0  0.0   2420  1164 ?        S    12:45   0:00 imap
| 70000     5698  0.0  0.0   2564  1200 ?        S    12:45   0:00 imap
`--

> In my setup where you assign separate UIDs to each user, the attacking 
> user can only read/modify the files that he has UNIX filesystem permission 
> to read/modify.  That would limit the attacker to only being able to 
> destroy his own mail, unlike the virtual user setup.
> 
>> Virtual users do not have all of their data jumbled together into one 
>> file, which seems to me anyway what you are referring to.
> 
> No, I meant filesystem-level permissions.  Obviously no one is talking 
> about different users having "all their data jumbled together into one 
> file"; sorry if I wasn't clear.

Filesystem-level permissions are also possible with virtual Users:

,--[ `ls -l /srv/mail/1/70003 | tail -n 5` ]--
| drwx------ 3 70007 70003 4096 2007-12-31 17:48 70007
| drwx------ 3 70008 70003 4096 2007-10-16 23:07 70008
| drwx------ 3 70009 70003 4096 2007-10-16 23:08 70009
| drwx------ 3 70010 70003 4096 2007-10-16 23:08 70010
| drwx------ 3 70011 70003 4096 2007-12-31 18:19 70011
`--


> This has the side-effect of not using UNIX UIDs to isolate the different 
> users' data from each other.

Oh, would you please explain why this should be?

> Because you can gain the benefit of UNIX filesystem permissions.

It's also possible with virtual domains/users.

> I am sure what I'm trying to describe here; it's scenario 1.  It should be 
> "trivial", just like adding new virtual users, and I believe the above is 
> the way to do it, but again I would double-check because I haven't done 
> this in a while and neglected to keep notes when I did it.
> 
> I hope that clears things up.  If this is getting off-topic and boring let 
> me know.


It is very trivial to manage multiple virtual domains with a lot of
virtual users:

,--[ stdout ]--
| hostname ~ # vmm da new.exmple.com
| hostname ~ # vmm useradd a.user at new.exmple.com
| Enter new password:
| Retype new password:
| hostname ~ # vmm ua b.user at new.exmple.com p4s5W0rd
| hostname ~ # vmm aa c.user at new.exmple.com b.user at new.exmple.com
| hostname ~ # vmm di new.exmple.com detailed | tail -n 9
| Available accounts
| ------------------
|         a.user at new.exmple.com
|         b.user at new.exmple.com
|
| Available aliases
| -----------------
|        c.user at new.exmple.com
`--

Regards
Pascal