"Kamil Rytarowski" writes:
> Module Name: src
> Committed By: kamil
> Date: Sun Nov 6 16:24:16 UTC 2016
>
> Modified Files:
> src/tests/kernel: t_ptrace.c
>
> Log Message:
> Add new tests attach_pid0 and attach_pid1 to t_ptrace
>
> attach_pid0 asserts that it is not valid to atta
On Thu, 10 Nov 2016, matthew green wrote:
"Kamil Rytarowski" writes:
Module Name:src
Committed By: kamil
Date: Sun Nov 6 16:24:16 UTC 2016
Modified Files:
src/tests/kernel: t_ptrace.c
Log Message:
Add new tests attach_pid0 and attach_pid1 to t_ptrace
attach_pid0 asse
> >> Log Message:
> >> Add new tests attach_pid0 and attach_pid1 to t_ptrace
> >>
> >> attach_pid0 asserts that it is not valid to attach PID 0 as it is a special
> >> kernel process.
> >>
> >> assert_pid1 asserts that non-root user cannot attach to PID 1 as it is the
> >> /dev/init process. This t
On Thu, 10 Nov 2016, matthew green wrote:
also, root can't attach to pid1 if securelevel is >= 0.
To adjust securelevel this test would need to be modified to run under
rump ... We wouldn't want the test to manipulate securelevel of the
running system.
s/wouldn't want/*can't* by design have
On 10.11.2016 03:28, Paul Goyette wrote:
> On Thu, 10 Nov 2016, matthew green wrote:
>
also, root can't attach to pid1 if securelevel is >= 0.
>>>
>>> To adjust securelevel this test would need to be modified to run under
>>> rump ... We wouldn't want the test to manipulate securelevel of
it would actually be useful to have a testcase that ran iff
root *and* securelevel >= 0 and tests it is unable to attach
to pid 1.
thanks.
.mrg.
is the problem fixed in -current? if not please someone commit the
fix ASAP. this should have been reverted the instant it was identified
as being problematic. that was days ago!
.mrg.
On 10.11.2016 03:44, matthew green wrote:
> it would actually be useful to have a testcase that ran iff
> root *and* securelevel >= 0 and tests it is unable to attach
> to pid 1.
>
> thanks.
>
>
> .mrg.
>
OK, I will have a look at it.
signature.asc
Description: OpenPGP digital signature