reads OK for me as well
On 10:28 Sat 03 Nov , Claudio Jeker wrote:
> On Sat, Nov 03, 2018 at 10:24:23AM +0100, Remi Locherer wrote:
> > On Tue, Oct 30, 2018 at 05:31:04PM +, Ricardo Mestre wrote:
> > > clearly an oversight due to looking at too many daemons at the same
> > > time. since th
On Sat, Nov 03, 2018 at 10:24:23AM +0100, Remi Locherer wrote:
> On Tue, Oct 30, 2018 at 05:31:04PM +, Ricardo Mestre wrote:
> > clearly an oversight due to looking at too many daemons at the same
> > time. since the only thing ripd needs to do is unlink the socket I think
> > we can remove con
On Tue, Oct 30, 2018 at 05:31:04PM +, Ricardo Mestre wrote:
> clearly an oversight due to looking at too many daemons at the same
> time. since the only thing ripd needs to do is unlink the socket I think
> we can remove control_cleanup, even though I'd rather do this
> introducing pledge, but
Sebastian Benoit wrote:
> Florian Obser(flor...@openbsd.org) on 2018.10.30 18:32:15 +0100:
> > On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote:
> > > Remi Locherer wrote:
> > >
> > > > On Tue, Oct 30, 2018 at 03:20:35PM +, Ricardo Mestre wrote:
> > > > > Hi,
> > > > >
> > > >
>From my point of view, and my sole opinion, the process running as root
from a long standing daemon, and which is not under a chroot, should not have
the hability to write and/or create files (even better if it cannot even
read). But we should reach a consensus once again, and if control_cleanup()
Florian Obser(flor...@openbsd.org) on 2018.10.30 18:32:15 +0100:
> On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote:
> > Remi Locherer wrote:
> >
> > > On Tue, Oct 30, 2018 at 03:20:35PM +, Ricardo Mestre wrote:
> > > > Hi,
> > > >
> > > > After all files are opened ripd(8) can
On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote:
> Remi Locherer wrote:
>
> > On Tue, Oct 30, 2018 at 03:20:35PM +, Ricardo Mestre wrote:
> > > Hi,
> > >
> > > After all files are opened ripd(8) can have the fs access disabled just
> > > before
> > > each process main loop. It
clearly an oversight due to looking at too many daemons at the same
time. since the only thing ripd needs to do is unlink the socket I think
we can remove control_cleanup, even though I'd rather do this
introducing pledge, but for now it's a great compromise.
OK?
Index: control.c
Remi Locherer wrote:
> On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote:
> > Remi Locherer wrote:
> >
> > > On Tue, Oct 30, 2018 at 03:20:35PM +, Ricardo Mestre wrote:
> > > > Hi,
> > > >
> > > > After all files are opened ripd(8) can have the fs access disabled just
> > > >
On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote:
> Remi Locherer wrote:
>
> > On Tue, Oct 30, 2018 at 03:20:35PM +, Ricardo Mestre wrote:
> > > Hi,
> > >
> > > After all files are opened ripd(8) can have the fs access disabled just
> > > before
> > > each process main loop. It
Remi Locherer wrote:
> On Tue, Oct 30, 2018 at 03:20:35PM +, Ricardo Mestre wrote:
> > Hi,
> >
> > After all files are opened ripd(8) can have the fs access disabled just
> > before
> > each process main loop. Its 2 childs already run under chroot, but since
> > they
> > are still not pled
On Tue, Oct 30, 2018 at 03:20:35PM +, Ricardo Mestre wrote:
> Hi,
>
> After all files are opened ripd(8) can have the fs access disabled just before
> each process main loop. Its 2 childs already run under chroot, but since they
> are still not pledged at least they have no way to read/write/c
ok benno@
Ricardo Mestre(ser...@helheim.mooo.com) on 2018.10.30 15:20:35 +:
> Hi,
>
> After all files are opened ripd(8) can have the fs access disabled just before
> each process main loop. Its 2 childs already run under chroot, but since they
> are still not pledged at least they have no
Hi,
After all files are opened ripd(8) can have the fs access disabled just before
each process main loop. Its 2 childs already run under chroot, but since they
are still not pledged at least they have no way to read/write/create files
within
the chroot. No loads or reloads of the config file hap
14 matches
Mail list logo