[Dovecot] cgroup support
Hi,
I am setting up a system that enforces cgroup restrictions when a user logs in via SSH, and for all the services that are run by a particular user.
I am also running dovecot to give users IMAP/POP access to their mailboxes. However, to be part of a cgroup, PIDs must be explicitly added to the cgroup tasks file. So for now, all my processes are run with resource restrictions, except for Dovecot processes.
It would be really cool if dovecots child/worker processes could be added the a cgroup in addition to the usual setuid/chroot protections that already exists. Adding a process to a cgroup is a matter of writing the PID to the correct cgroup tasks file.
If this were implemented as an extra field in userdb, it could be very powerful, and allow for all kinds of resource management/accounting of dovecot processes.
This would obviously not be cross-platform, since cgroups are a feature of the Linux kernel. Would that be a problem?
Is support for cgroups something that could be considered for dovecot at all? Are there other ways to put dovecot processes in cgroups?
I do not really have a patch or a plan for how everything would work out in detail. If this would be useful for dovecot, I would be happy to start hacking on a patch.
Cheers Andreas
Have you tried post login scripts ?
On Sun, 30 Jan 2011 13:28:22 +0100, Andreas Pelme <andreas@pelme.se> wrote:
Hi,
I am setting up a system that enforces cgroup restrictions when a user logs in via SSH, and for all the services that are run by a particular user.
I am also running dovecot to give users IMAP/POP access to their mailboxes. However, to be part of a cgroup, PIDs must be explicitly added to the cgroup tasks file. So for now, all my processes are run with resource restrictions, except for Dovecot processes.
It would be really cool if dovecots child/worker processes could be added the a cgroup in addition to the usual setuid/chroot protections that already exists. Adding a process to a cgroup is a matter of writing the PID to the correct cgroup tasks file.
If this were implemented as an extra field in userdb, it could be very powerful, and allow for all kinds of resource management/accounting of dovecot processes.
This would obviously not be cross-platform, since cgroups are a feature of the Linux kernel. Would that be a problem?
Is support for cgroups something that could be considered for dovecot at all? Are there other ways to put dovecot processes in cgroups?
I do not really have a patch or a plan for how everything would work out in detail. If this would be useful for dovecot, I would be happy to start hacking on a patch.
Cheers Andreas
-- Emerson Pinter Picture Internet +55 11 5089 8100 http://www.picture.com.br/
On Sun, 2011-01-30 at 17:03 +0100, Andreas Pelme wrote:
On 30 jan 2011, at 16:05, Emerson Pinter wrote:
Have you tried post login scripts ?
Wow, I had missed the post login scripts. That will solve this problem very nicely!
Hmm. With v1.x it works, but in v2.0 the post-login scripts are run in a separate process and I don't think you can get the PID there without some changes to code..
I think the current pid(from postlogin script) is sufficient if the imap binary will be a child process. The cgroup is inherited from parent process (at least the kernel documentation says that)...
Emerson Pinter
On 30-01-2011 14:10, Timo Sirainen wrote:
On Sun, 2011-01-30 at 17:03 +0100, Andreas Pelme wrote:
On 30 jan 2011, at 16:05, Emerson Pinter wrote:
Have you tried post login scripts ?
Wow, I had missed the post login scripts. That will solve this problem very nicely!
Hmm. With v1.x it works, but in v2.0 the post-login scripts are run in a separate process and I don't think you can get the PID there without some changes to code..
With v2.0 the imap and post-login processes are both created by the dovecot process. So no parent-child relationship between them.
On 31.1.2011, at 14.00, Emerson Pinter wrote:
I think the current pid(from postlogin script) is sufficient if the imap binary will be a child process. The cgroup is inherited from parent process (at least the kernel documentation says that)...
Emerson Pinter
On 30-01-2011 14:10, Timo Sirainen wrote:
On Sun, 2011-01-30 at 17:03 +0100, Andreas Pelme wrote:
On 30 jan 2011, at 16:05, Emerson Pinter wrote:
Have you tried post login scripts ?
Wow, I had missed the post login scripts. That will solve this problem very nicely!
Hmm. With v1.x it works, but in v2.0 the post-login scripts are run in a separate process and I don't think you can get the PID there without some changes to code..
On 31 jan 2011, at 15:07, Timo Sirainen wrote:
With v2.0 the imap and post-login processes are both created by the dovecot process. So no parent-child relationship between them.
Would it be possible to specify an alternative mail_executable that wraps the imap/pop processes?
I.e. something like:
protocol imap { mail_executable = cgroup_wrapper.sh }
cgroup_wrapper.sh: #!/bin/sh echo $$ > /cgroup/foo/bar/tasks exec /usr/libexec/dovecot/imap $*
Is the privileges dropped before mail_executable is called, or is it done in the mail_executable itself?
Cheers Andreas
On 1.2.2011, at 9.44, Andreas Pelme wrote:
On 31 jan 2011, at 15:07, Timo Sirainen wrote:
With v2.0 the imap and post-login processes are both created by the dovecot process. So no parent-child relationship between them.
Would it be possible to specify an alternative mail_executable that wraps the imap/pop processes?
Maybe.
I.e. something like:
protocol imap { mail_executable = cgroup_wrapper.sh }
cgroup_wrapper.sh: #!/bin/sh echo $$ > /cgroup/foo/bar/tasks exec /usr/libexec/dovecot/imap $*
Is the privileges dropped before mail_executable is called, or is it done in the mail_executable itself?
If you have virtual users, you can do:
service imap { executable = cgroup_wrapper.sh user = vmail drop_priv_before_exec = yes }
With system users you can't do that.
participants (3)
-
Andreas Pelme
-
Emerson Pinter
-
Timo Sirainen