Changeset View
Standalone View
sys/sys/event.h
| Show First 20 Lines • Show All 196 Lines • ▼ Show 20 Lines | #define NOTE_CLOSE 0x0100 /* file closed, fd did not | ||||
| allowed write */ | allowed write */ | ||||
| #define NOTE_CLOSE_WRITE 0x0200 /* file closed, fd did allowed | #define NOTE_CLOSE_WRITE 0x0200 /* file closed, fd did allowed | ||||
| write */ | write */ | ||||
| #define NOTE_READ 0x0400 /* file was read */ | #define NOTE_READ 0x0400 /* file was read */ | ||||
| /* | /* | ||||
| * data/hint flags for EVFILT_PROC and EVFILT_PROCDESC, shared with userspace | * data/hint flags for EVFILT_PROC and EVFILT_PROCDESC, shared with userspace | ||||
| */ | */ | ||||
| #define NOTE_EXIT 0x80000000 /* process exited */ | #define NOTE_EXIT 0x80000000 /* proc/procdesc: process | ||||
| #define NOTE_FORK 0x40000000 /* process forked */ | exited */ | ||||
markj: Why repurpose NOTE_FORK? Isn't it possible someone might want to use a procdesc to wait for… | |||||
Done Inline ActionsShould we ever allow it? NOTE_FORK is very close to limited tracing functionality, and you was explicitly against the ptrace attach over procdesc I just acted under assumption that procdesc knote actions should not extend the functionality of existing syscalls, mainly pdwait(). If you prefer, I can reuse the free bit from PCTRLMASK but may be instead we should split the namespace between _PROC and _PROCDESC filters? kib: Should we ever allow it? NOTE_FORK is very close to limited tracing functionality, and you was… | |||||
Not Done Inline Actions
Well, to be clear, I was against enabling ptrace() in capability mode, at least without some more design and discussion; PT_ATTACH_PD on its own is fine I suppose, but I do not really see the point unless you want to enable capmode ptrace(). Meanwhile, NOTE_FORK already exists, and supporting it from procdesc does not require much complexity (I think?), and procdescs already implement NOTE_EXIT. Plus, with procdescs you can avoid PID reuse races. For ptrace() I think such races are probably not a real concern (but correct me if I am wrong). So, I think it makes some sense to leave NOTE_FORK available for procdescs. BTW, does anything prevent a capmode process from using EVFILT_PROC? If not, then that is a bug. markj: > you was explicitly against the ptrace attach over procdesc
Well, to be clear, I was against… | |||||
Done Inline Actions
For ptrace() the races are impossible since the target is reparented to the debugger.
Ok, consumed the new bit for NOTE_PDSIGCHLD.
Yes, this seems to be a bug. It is easy to disallow registering new knotes when in cap mode. What should we do about knotes that are were registered before entering the cap mode? kib: > > you was explicitly against the ptrace attach over procdesc
>
> Well, to be clear, I was… | |||||
Not Done Inline Actions
Maybe kqueue filters with f_isfd == 0 should be disallowed by default in capability mode, with some mechanism to opt in. We have:
The only real choices seem to be 1) ignore them, 2) in cap_enter(), go through all of the process' kqueues and knotes, and somehow purge them. I think 1) is probably acceptable. 2) is significant complexity for a very rare and easily avoidable situation. Maybe @emaste or @oshogbo have an opinion there. markj: > It is easy to disallow registering new knotes when in cap mode.
Maybe kqueue filters with… | |||||
| #define NOTE_EXEC 0x20000000 /* process exec'd */ | #define NOTE_FORK 0x40000000 /* proc: process forked */ | ||||
| #define NOTE_EXEC 0x20000000 /* proc: process exec'd */ | |||||
| #define NOTE_PDSIGCHLD 0x10000000 /* procdesc: pdwait() info | |||||
| available */ | |||||
| #define NOTE_PCTRLMASK 0xf0000000 /* mask for hint bits */ | #define NOTE_PCTRLMASK 0xf0000000 /* mask for hint bits */ | ||||
| #define NOTE_PDATAMASK 0x000fffff /* mask for pid */ | #define NOTE_PDATAMASK 0x000fffff /* mask for pid */ | ||||
| /* additional flags for EVFILT_PROC */ | /* additional flags for EVFILT_PROC */ | ||||
| #define NOTE_TRACK 0x00000001 /* follow across fork/create */ | #define NOTE_TRACK 0x00000001 /* follow across fork/create */ | ||||
| #define NOTE_TRACKERR 0x00000002 /* could not track child */ | #define NOTE_TRACKERR 0x00000002 /* could not track child */ | ||||
| #define NOTE_CHILD 0x00000004 /* am a child process */ | #define NOTE_CHILD 0x00000004 /* am a child process */ | ||||
| ▲ Show 20 Lines • Show All 177 Lines • Show Last 20 Lines | |||||
Why repurpose NOTE_FORK? Isn't it possible someone might want to use a procdesc to wait for NOTE_FORK events?