On Mon, 30 Dec 2002, Rob Siemborski wrote:
> On Mon, 30 Dec 2002, Henrique de Moraes Holschuh wrote:
> > Yes. We cannot easily protect the mail spool without a lot of huge changes
> > to Cyrus. I think we would need to at least:
> >
> [snip]
> > 2. Use IPC/pipes/whatever to talk to master (or ano
On Mon, 30 Dec 2002, Henrique de Moraes Holschuh wrote:
> Yes. We cannot easily protect the mail spool without a lot of huge changes
> to Cyrus. I think we would need to at least:
>
[snip]
> 2. Use IPC/pipes/whatever to talk to master (or another long-running
> daemon), and let it keep all g
On Sun, 29 Dec 2002, Lawrence Greenfield wrote:
> --On Monday, December 30, 2002 12:52 AM -0200 Henrique de Moraes Holschuh
> <[EMAIL PROTECTED]> wrote:
> >The codepaths in master are MUCH easier to audit, so I think it overall
> >enhances the security of Cyrus to run services inside chroot jails.
--On Monday, December 30, 2002 12:52 AM -0200 Henrique de Moraes Holschuh
<[EMAIL PROTECTED]> wrote:
The codepaths in master are MUCH easier to audit, so I think it overall
enhances the security of Cyrus to run services inside chroot jails. IF it
is done right.
Any comments? Should I submit thi
Duh. Please apply the attached patch too. I really should regression-test
these things BEFORE I send out patches...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon
The attached patch adds chroot() jailing support to Cyrus master.
Here's the catch:
1. If no jail= parameters are set, cyrus behaves exactly as it always did
2. If jail= parameters are set, we NEED to keep superuser privileges
so that we can chroot(). That means:
2a. If your system has set
