YAMAMOTO Takashi wrote:

>>> why this patch doesn't have amd64 part?
>> what should we change for amd64?
>>
>> phyre:arch {31} egrep 'HAVE_(PTRACE|PROCFS)_MACHDEP' i386/include/*
>> i386/include/ptrace.h:#define   __HAVE_PTRACE_MACHDEP
>> i386/include/ptrace.h:#define   __HAVE_PROCFS_MACHDEP
>> phyre:arch {32} egrep 'HAVE_(PTRACE|PROCFS)_MACHDEP' amd64/include/*
>> phyre:arch {33}
>>
>> (I think whoever did amd64 did some heavy copy/paste ;)
> 
> if procfs_machdep_rw is merely dead code, it's fine.

it's dead code. I'll remove it.

>> proc_isunder() should be in the secmodel.
> 
> do you mean chroot(8) should be a part of secmodel?

it already kinda is. we don't provide any context (yet) but there is
a chroot action. I would like to move proc_isunder() to the secmodel
code, yes.

>>> does it mean to prohibit even reading of init's status if securelevel >= 0?
>> yeah. can change, but again, we need to pass more context.
> 
> why don't you pass the necessary context?

we have two args to play with. assuming they all need the tracer too,
that leaves us with one argument free. that's not enough for at least
procfs. if I can shift the subsystem to the action itself, as I
suggested, I can pass more context.

>>> i'm not sure if it's a good idea to make every callers of process_doXXX
>>> use kauth_foo() directly.  maybe it depends how much/kind of contexts you
>>> will pass to listeners, tho.
>> see above wrt/context. "<lwp> wants to use procfs to <r/w> on <node>",
>> "<lwp> wants to use ptrace to <req> on <proc>", etc.
> 
> i wonder whether process_doXXX or its callers is a better place to
> call kauth_foo().

issue is that process_doXXX don't know who called them, ptrace or procfs
or whatever subsystem that we may introduce in the future.

-e.

-- 
Elad Efrat