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
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
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
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.
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.
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
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
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
14 matches
Mail list logo
