Virtual users or system users for a mail server

[Marc Aymerich]

Everybody seems to be configuring their mail server using virtual users
instead of the traditional system user approach.

I find system users easy to configure and even more secure, since IMAP and
POP3 processes can run under the system user account (of course disabling
shell access).

I keep wondering if perhaps I'm missing some interesting advantage of using
virtual user accounts?

Anyone like to comment on this?

[Scott Blaydes]

Everybody seems to be configuring their mail server using virtual users instead of the traditional system user approach.
I find system users easy to configure and even more secure, since IMAP and POP3 processes can run under the system user account (of course disabling shell access).
I keep wondering if perhaps I'm missing some interesting advantage of using virtual user accounts?
Anyone like to comment on this?
--
Marc

My primary motivation to move to virtual users was to support multiple domains without username collisions. After a few scripts were written, I didn’t really see one as easier than the other for day to day use.

Thank you,
Scott Blaydes


Scott Blaydes
***@netteksolutions.com /\ "Encrypt all the things"
------------------------------------------- / \ /--------------------------------------
325-320-7526 \/ Encrypted email preferred.
9508 837D B072 4E0B BDAB FA4D 096E ECF0 D8A2 381E

[Sven Hartge]

Post by Marc Aymerich
Everybody seems to be configuring their mail server using virtual
users instead of the traditional system user approach.
I find system users easy to configure and even more secure, since IMAP
and POP3 processes can run under the system user account (of course
disabling shell access).
I keep wondering if perhaps I'm missing some interesting advantage of
using virtual user accounts?
Anyone like to comment on this?

Supporting IMAP shared folders with seperate users is a major pain in
the lower back. This only really works painless if you only use one user
for the mails on the mail-server and and IMAP ACLs on top of that.

Also it allows you to support multiple domains without having to worry
about username collisions.

Third point: I don't have to add any NSS providers like libnss-ldapd or
libnss-mysql to my mail-servers, only the mail handling daemons (exim4,
postfix, dovecot) need to know the users. This reduces the complexity in
a bigger system quite a bit.

Grüße,
Sven.

[Marc Aymerich]

Thanks for your comments !

We're currently avoiding name collisions with virtual domains solely, we
only have one local domain which all the others virtual, users to domains
are mapped by virtual_maps.

One thing that I'm not quite sure about is how to deal with user provided
procmails, since the process which executes them has privileges for all
vmailboxes, this sounds like a security problem. Perhaps I'm mistaken or
missing something here. Do you guys need to provide this kind of service on
your mail servers (user provider procmail or sieve) ?

Post by Sven Hartge

Post by Marc Aymerich
Everybody seems to be configuring their mail server using virtual
users instead of the traditional system user approach.
I find system users easy to configure and even more secure, since IMAP
and POP3 processes can run under the system user account (of course
disabling shell access).
I keep wondering if perhaps I'm missing some interesting advantage of
using virtual user accounts?
Anyone like to comment on this?

Supporting IMAP shared folders with seperate users is a major pain in
the lower back. This only really works painless if you only use one user
for the mails on the mail-server and and IMAP ACLs on top of that.
Also it allows you to support multiple domains without having to worry
about username collisions.
Third point: I don't have to add any NSS providers like libnss-ldapd or
libnss-mysql to my mail-servers, only the mail handling daemons (exim4,
postfix, dovecot) need to know the users. This reduces the complexity in
a bigger system quite a bit.
GrÌße,
Sven.
--
Sigmentation fault. Core dumped.
--
with a subject of "unsubscribe". Trouble? Contact

[Sven Hartge]

Post by Marc Aymerich
One thing that I'm not quite sure about is how to deal with user provided
procmails, since the process which executes them has privileges for all
vmailboxes, this sounds like a security problem. Perhaps I'm mistaken or
missing something here. Do you guys need to provide this kind of service on
your mail servers (user provider procmail or sieve) ?

Solution is simple: don't provide procmail as filtering solution, use
Sieve to allow users to filter their mails.

Grüße,
Sven.

[Raoul Bhatia]

Post by Marc Aymerich

Post by Marc Aymerich
One thing that I'm not quite sure about is how to deal with user

provided

Post by Marc Aymerich
procmails, since the process which executes them has privileges for

all

Post by Marc Aymerich
vmailboxes, this sounds like a security problem. Perhaps I'm mistaken

or

Post by Marc Aymerich
missing something here. Do you guys need to provide this kind of

service on

Post by Marc Aymerich
your mail servers (user provider procmail or sieve) ?

Solution is simple: don't provide procmail as filtering solution, use
Sieve to allow users to filter their mails.
Grüße,
Sven.

AFAIRC there is a virtual uid mapping available which can query a database, LDAP etc..

Cheers,
Raoul

[Sven Hartge]

Post by Raoul Bhatia

Post by Sven Hartge

Post by Marc Aymerich
One thing that I'm not quite sure about is how to deal with user
provided procmails, since the process which executes them has
privileges for all vmailboxes, this sounds like a security problem.
Perhaps I'm mistaken or missing something here. Do you guys need to
provide this kind of service on your mail servers (user provider
procmail or sieve) ?

Solution is simple: don't provide procmail as filtering solution, use
Sieve to allow users to filter their mails.

AFAIRC there is a virtual uid mapping available which can query a database, LDAP etc..

Still: procmail is "evil" and full of security nightmares if you try to
use it inside a virtual user context.

It was initially built to be used from the .forward file of a user and
to be run as the specific user the mail was delivered to.

And then there is the problem of how to allow users to provide their own
procmailrc. Because procmail is so powerful and its configuration syntax
is so complex, it will be very difficult to write a parser to detect a)
malformed config files and b) harmful config files.

Of course you can write a very simple web interface, only allowing
filtering of mails by specific criteria into specific folders, thus
limiting the attack vectors by limiting the used features of procmail.

But then you may also use Sieve in the first place, which provides a
well-defined protocol to allow the users to securely update the filter
file themselves.

Sieve on the other hand was designed with virtual users in mind. If
implemented correctly, no user is able to write to a different mailbox
than his own. Also per default you cannot execute any commands on the
host and also limit the possibility to redirect mails to other
(external) mail-adresses.

All in all: procmail is dead (at least in a virtual user multi hosting
scenario), all hail Sieve!

Grüße,
Sven.