Is your feature request related to a problem? Please describe.

With ScompFilterAttr::ApiSysRawRc enabled, some libseccomp apis will return a system's errno instead of ECANCELED.
But, current implementations cannot handle the system's errno other than SeccompErrono, so users have to extract the errno by themselves using std::io::Error::last_os_error(). This is a little bit tiring.

Describe the solution you'd like

There are some solutions to tackle the problem.

1. Add SYSRAW(i32) to SeccompError:
   Example:

pub enum SeccompErrno {
    ...
    SYSRAW(i32),
}

2. Add SYSRAW(i32) to ErrorKind:
   Example:

pub(crate) enum ErrorKind {
    ...
    SYSRAW(i32),
}

3. Add all errno to SeccompErrno (#205 approach):
   Example:

pub enum SeccompErrno {
    ...
   EBUSY,
   EBADFD
}

Ref. https://docs.rs/nix/latest/src/nix/errno.rs.html#1125-1257

4. Use nix::Errno instead of SeccompErrno (stop maintaining SeccompErrno).
   Example:

pub(crate) enum ErrorKind {
    /// An error that represents error code on failure of the libseccomp API.
    Errno(nix:Errno),
    /// A parse error occurred while trying to convert a value.
    ParseError,
    ...
}

The arguments of ScmpArgCompare::new are a bit confusing ATM. In the most cases the third argument is the value with which the argument is compared and the fourth argument is None. If you use Some(_) for the fourth argument, it is no effect. The fourth argument is therefore effectively ignore. But if you use masked equality, the third argument is the mask and the fourth argument is the value used for comparison. And if you specify it as None you implicitly specified 0. Not really a nice way for a high-level wrapper.

The first Idea would be to make the third argument always be the value and the fourth argument to be the mask (still and Option<_>). However this silently changes behaviour in a drastically way for people who just upgrade the version in Cargo.toml without reading the CHANGELOG. Moreover it would not solve the ugly None.

You could create a new_masked function. However making one op part of ScmpArgCompare isn't a code API design IMHO.

My current idea is to move the mask into ScmpCompareOp. So

ScmpArgCompare::new(0, ScmpCompareOp::Greater, 2, None);
ScmpArgCompare::new(0, ScmpCompareOp::MaskedEqual, 0b0010, Some(3));

becomes

ScmpArgCompare::new(0, ScmpCompareOp::Greater, 2);
ScmpArgCompare::new(0, ScmpCompareOp::MaskedEqual(0b0010), 3);

WDYT?

Describe the bug
Build failure when use with thiserror

To Reproduce

Code:

use libseccomp::*;

#[derive(thiserror::Error, Debug)]
pub enum Error {
    #[error("{0}")]
    SeccompError(#[from] libseccomp::SeccompError),
}

fn main() -> Result<(), Error> {
    // Creates and returns a new filter context.
    let mut filter = ScmpFilterContext::new_filter(ScmpAction::Allow)?;

    // Adds an architecture to the filter.
    filter.add_arch(ScmpArch::X8664)?;

    // Returns the number of a syscall by name.
    let syscall = ScmpSyscall::from_name("dup3")?;

    // Adds a single rule for an unconditional action on the syscall.
    filter.add_rule(ScmpAction::Errno(10), syscall)?;

    // Loads the filter context into the kernel.
    filter.load()?;

    // The dup3 fails by the seccomp rule.
    assert_eq!(
        unsafe { libc::dup3(0, 100, libc::O_CLOEXEC) } as i32,
        -libc::EPERM
    );
    assert_eq!(std::io::Error::last_os_error().raw_os_error().unwrap(), 10);

    Ok(())
}

Compile with:
cargo build

See error:

error[E0603]: struct `SeccompError` is private
  --> src/main.rs:6:38
   |
6  |     SeccompError(#[from] libseccomp::SeccompError),
   |                                      ^^^^^^^^^^^^ private struct
   |
note: the struct `SeccompError` is defined here
  --> .../libseccomp-0.2.3/src/lib.rs:56:21
   |
56 | use error::{Result, SeccompError};
   |                     ^^^^^^^^^^^^

Expected behavior
Build success.

Environment

• libseccomp: 0.5.4.1
• libseccomp-rs: 0.2.3
• Rust: rustc 1.62.1 (e092d0b6b 2022-07-16)
• Linux: 5.18.16-arch1-1
• Architecture: x86_64

Current Seccomp Notification implementation is not good as high-level wrapper.
Hence, we have to rework Seccomp Notification based on libseccomp-golang.
This work changes the API interfaces dramatically, but now is the perfect time to rework this while there are not many users who currently are using Seccomp Notification through libseccomp-rs.

In addtion, I'll add the documentation and unit tests about it,

Add the following functions like the existing {get,set}_no_new_privs_bit().

• get_act_default()
• {get,set}_act_badarch()
• {get,set}_ctl_nnp()
• {get,set}_ctl_tsync()
• {get,set}_ctl_log()
• {get,set}_ctl_ssb()
• {get,set}_ctl_optimize()
• {get,set}_api_sysrawrc()

It would be better to create CONTRIBUTING.md for the libseccomp-rs project.

impl ScmpFilterContext {
    pub fn set_syscall_priority(&mut self, syscall: i32, priority: u8) -> Result<()> {
        ...
    }
}

https://man7.org/linux/man-pages/man3/seccomp_syscall_priority.3.html

Release:
libseccomp: v0.2.1

TODO:

• Merge #75 into main branch
• Validate the crate documentation
• Change cargo.toml/README.md of the libseccomp crate for v0.2.1
• Create v0.2.1 tag
• Publish the crates on crates.io
  • Run cargo doc --no-deps
• Create the release page in Github

libseccomp provides a SCMP_SYS macro to resolve syscall names to numbers at compile time. This is faster and handier than seccomp_syscall_resolve_name ScmpSyscall::from_name.

Definition in seccomp.h:

#define SCMP_SYS(x)     (__SNR_##x)

__SNR_* is defined in seccomp-syscalls.h to either __NR_* if it is defined or __PNR_* (a negative pseudo number).

It would be nice if this static resolving of syscall names would be available in Rust to.

Other helpful resource:

• https://github.com/seccomp/libseccomp/blob/main/src/syscalls.csv (generated by https://github.com/seccomp/libseccomp/blob/main/src/arch-syscall-validate)
• https://github.com/jasonwhite/syscalls/blob/master/build.rs

Upstream commit: seccomp/libseccomp@3f0e47f (not release yet)

libseccomp-sys:

extern "C" {
    /// Generate seccomp Berkeley Packet Filter (BPF) code and export it to a buffer
    ///
    /// - `ctx`: the filter context
    /// - `buf`: the destination buffer
    /// - `len`: on input the length of the buffer, on output the number of bytes in the program
    ///
    /// This function generates seccomp Berkeley Packer Filter (BPF) code and writes
    /// it to the given buffer.  Returns zero on success, negative values on failure.
    pub fn seccomp_export_bpf_mem(ctx: const_scmp_filter_ctx, buf: *mut /* FIXME */, len: *mut c_size_t) -> c_int;
}

libseccomp:

impl ScmpFilterContext {
    pub fn export_bpf_mem(&self) -> Vec<u8> {
        ...
    }
}

v0.2.0 milestone: https://github.com/libseccomp-rs/libseccomp-rs/milestone/1

Release:
libseccomp: v0.2.0
libseccomp-sys: v0.2.0

TODO:

• Merge all PRs in the milestone into main branch
• Update CHANGELOG.md
  • Add all changes from v0.1.3
  • The interfaces will be changed dramatically from v0.2.0, so we MUST write the annotations of the change.
• Validate the crate documentation
• Change cargo.toml/README.md of libseccomp/libseccomp-sys for v0.2.0
• Create v0.2.0 tag
• Publish the crates on crates.io
  • Run cargo doc --no-deps
  • At first, I need to pubslih the libseccomp-sys crate. Second, I'll publish the libseccomp crate.
• Create the release page in Github

There are CI warnings because

• GitHub Actions: All Actions will begin running on Node16 instead of Node12
• GitHub Actions: Deprecating save-state and set-output commands

All come from action-rs/toolchain and actions-rs/tarpaulin. For action-rs/toolchain they are tracked in actions-rs/toolchain#221 and actions-rs/toolchain#219. While actions-rs/tarpaulin does not have an issue for them yet.

Since both actions do not seem to see that much maintenance (last release ~1,5 years ago, Open PRs w/o any comments for over 1 year, Unmerged dependabot PRs with security updates, ...) I would put up for discussion whether we should not better get rid of them to avoid future problems.

• ScmpFd
• ScmpFilterContext::export_{bpc,pfc}

It looks like there are cases where programs need to know the errno returned by libseccomp.
Example at https://github.com/flatpak/flatpak/blob/8ad534f65c48ff0a91f6f4472924b152752bbf74/common/flatpak-run.c#L3292.

We should add an errno(&self) -> Option<Errno> function to SeccompError.

Tasks (draft):

• Add errno field to SeccompError
• Add errno getter function to `SeccompError
• Add SeccompErrno type (enum)
• Make sure errno is saved in all relevant places
• Remove ErrorKind::Errno
• Use SeccompErrno for fmt:Display.

Currently, all unit tests for the libsecomp crate is under the same file as the to-be-tested code.
I think it's right to put unit tests with the production code as Rust book mentioned here, but we'll lose an overview and a clear separation between production and test code.
Also, the files'll grow huge while containing both.

Hence, I'd like to move unit tests to a tests directory on top for making the code clean.
Originally, the tests directory is for integration tests, but it's good for the future work.

├── libseccomp-rs
│   └── libseccomp
│   └── libseccomp-sys
│   └── tests
│        └── xxx.rs

Or, we'll need to split the current huge lib.rs as module like notify.rs

If seccomp_reset() is called with a NULL filter, it resets the library's global task state, including any notification file descriptors retrieved by seccomp_notify_fd(3). Normally this is not needed, but it may be required to continue using the library after a fork() or clone() call to ensure the API level and user notification state is properly reset.

#13 has changed ScmpAction::Errno(u32) to ScmpAction::Errno(i32) to make ScmpAction::Errno(libc::EPERM) as easy as possible.

However since you can only use u16, it would be good if it would be ScmpAction::Errno(u16).
Now my idea is to change it to ScmpAction::Errno(u16) and provide ScmpAction::errno(errno: i32) -> Self (this will also simplify from_str's val).

Some current unit tests such as test_get_syscall_name_from_arch() just output a message using println!.
We need to fix the tests properly using assert macro.

Ref. #119 (comment)

How does argument comparison work in libseccomp?

You can either act on a syscall unconditional (no argument comparison) or conditional (i.e. based on the argument of the syscall. And no you can not dereference pointers.).

If you use argument comparison, you specify rules which compare the nth-value of a syscall to a datum value using a scmp_compare operator.

These rules are logically AND-ed:

If syscall argument comparisons are included in the filter rule, all of the comparisons must be true for the rule to match.

But even more important, you can only have one comparisons for an argument:

When adding syscall argument comparisons to the filter it is important to remember that while it is possible to have multiple comparisons in a single rule, you can only compare each argument once in a single rule. In other words, you can not have multiple comparisons of the 3rd syscall argument in a single rule.

If you try to add multiple comparisons for one argument, add_rule will return Err(_). That's perfectly fine. However from an user PoV it woulb be great if the API would not all this.

Ideas

1. Adopt libseccomp-golang like add_rule* methods:

   fn add_rule(&mut self, syscall: i32, action ScmpAction) -> Result<()>;
   fn add_rule_conditional(&mut self, syscall: i32, action ScmpAction, comparators: &[ScmpArgCompare]) -> Result<()>;
   fn add_rule_conditional_exact(&mut self, syscall: i32, action ScmpAction, comparators: &[ScmpArgCompare]) -> Result<()>;
   fn add_rule_exact(&mut self, syscall: i32, action ScmpAction) -> Result<()>;

2. Add an own ArgumentComparators type:

   // Same ABI: `&[libseccomp-sys::scmp_arg_cmp] as *const libseccomp-sys::scmp_arg_cmp` <=> `const struct scmp_arg_cmp *`
   struct ArgComp([libseccomp-sys::scmp_arg_cmp; 6]);
   impl ArgComp {
       pub fn get(n: usize) -> ScmpArgCompare;
       pub fn set(n: usize, op: ScmpCompareOp, datum: u64);
       pub fn set_noreplace(n: usize, op: ScmpCompareOp, datum: u64);
       pub fn from_iter(i: impl IntoIterator<Item = (ScmpCompareOp, u64)>) -> Result<Self>`
       pub fn from_iter(i: impl IntoIterator<Item = ScmpArgCompare) -> Result<Self>`
   }

   As you see this is an unfinish idea.
3. (Ab)use rust's operators:

   ctx.add_rule(ScmpAction::Allow, 1000, &[ARG0 == 5, ARG1 != 2, ARG2 >= 64, ARG3 & 0x0f0 == 1234])

   This is rust, not python so we need cmp![ARG0 == ….

Basically I want to simplify

ctx.add_rule(ScmpAction::Allow, 1000, Some(&[ScmpArgCompare::new(0, ScmpCompareOp::Equal, 1), ScmpArgCompare::new(2, ScmpCompareOp::NotEqual, 32)]))?;

to something like

ctx.add_rule(ScmpAction::Allow, 1000, ArgCmp(arg_0_eq(1), None, arg_2_ne(32)))?;

Obvious this needs some time, thinking, input, ...

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
#[repr(transparent)]
pub struct ScmpSyscall(i32);
impl ScmpSyscall {
    fn as_sys(self) -> i32 {
        ...
    }

    fn from_sys(nr: i32) -> Self {
        ...
    }

    pub fn from_name(name: &str) -> Result<Self> {
        ...
    }

    pub fn from_name_by_arch(name: &str, arch: ScmpArch) -> Result<Self> {
        ...
    }

    pub fn get_name(&self) -> Result<String> {
        ...
    }

    pub fn get_name_by_arch(&self, arch: ScmpArch) -> Result<String> {
        ...
    }
}

#[deprecated(since = "0.y.z", note = "Use ScmpSyscall::from_name/ScmpSyscall::from_name_by_arch instead.")]
fn get_syscall_from_name() {}
#[deprecated(since = "0.y.z", note = "Use ScmpSyscall::get_name_by_arch instead.")]
fn get_syscall_name_from_arch() {}

Note: This can be done after 0.2.0 without breaking existing code using an AsSyscall trait.

pub trait AsSyscall: private::Sealed {
    fn as_syscall_nr(&self) -> i32;
}

impl AsSyscall for ScmpSyscall {
    ...
}

impl AsSyscall for i32 {
    ...
}

mod private {
    pub trait Sealed {}

    impl Sealed for ScmpSyscall {}
    impl Sealed for i32 {}
}

impl ScmpFilterContext {
    pub fn add_rule<S: AsSyscall>(
        &mut self,
        action: ScmpAction,
        syscall: S,
        comparators: Option<&[ScmpArgCompare]>,
    ) -> Result<()> {}
}

RELEASE:
libseccomp: v0.3.0

TODO:

• Solve all PRs and issues in https://github.com/libseccomp-rs/libseccomp-rs/milestone/3
• Validate the crate documentation
  • Run cargo doc --no-deps
• Change Cargo.toml, README.md, and CHANGELOG.md for v.0.3.0
• Create v0.3.0 tag
• Publish the libseccomp crate on crates.io
• Create the release page in GitHub

To release v0.2.3, move {get,set}_api_tskip() to the next milestone.
Ref. #88 (comment)

with seccomp_syscall_resolve_name_rewrite() rewriting the syscall number for architectures that modify the syscall. Syscall rewriting typically happens in case of a multiplexed syscall, like socketcall(2) or ipc(2) on x86.

Together with #54

It would be better to re-export notify module so that users can use the more convenient structure as follows.

Before:

// Example
use libseccomp::*;

notify::notify_id_valid();

After:

// Example
use libseccomp::*;

notify_id_valid();

Currently, I plan to re-export the notify module as private module as follows in order to keep the documentation clean.
However, if I do, this will be a breaking change.

#[cfg(any(libseccomp_v2_5, doc))] 
mod notify;

If I re-export the notify module as public, this won't be a breaking change, but the re-exports section is added to the documentation as follows and it may be huge as new notify features are added. (I'd like to avoid writing pub use notify::*)

@rusty-snake Which do you prefer? (or Could you tell me the better solution if you have?)

Like /proc/self/mem or debuggers, spoofed syscall returns via unotify are an external entity too.

Is your feature request related to a problem? Please describe.

N/A

Describe the solution you'd like

struct ScmpNotifCookie(u64) or type ScmpNotifCookie = u64.
The latter wouldn't be a breaking change while the former would allow fn ScmpNotifCookie::is_valid(fd: ScmpFd) -> bool.

Describe alternatives you've considered

N/A

Additional context

N/A

impl ScmpFilterContext {
    pub fn add_rule_exact(...) {
        unsafe { seccomp_rule_add_exact_array(...)_}
    }
}

Ref. https://manpages.debian.org/jessie-backports/libseccomp-dev/seccomp_rule_add_array.3.en.html

We should add an example for userspace notifications to the crate root.

We should consider a ScmpArch::Unsupported(u32) variant which gets returned instead of ParseError by ScmpArch::native().

Discussed in #154

ScmpFilterContext::new_filter(ScmpAction::Allow)?
    .add_arch(ScmpArch::X8664)?;
    .add_rule(
        ScmpAction::Errno(libc::EPERM),
        ScmpSyscall::from_name("chroot")?,
    )?
    .add_rule(...)?
    .add_rule(...)?
    .add_rule_conditional(...)?
    .set_ctl_log(true)?
    .load()?;

IMHO, we should establish an MSRV.

There are two common MSRV concepts:

1. latest stable - offset (offset is usually 2).
   Example: The current stable rust version is 1.59, so we would CI check and guarantee that libseccomp-rs works with rust >= (1.59 - 2 = 1.57).
2. A fixed release (e.g. 1.56) which is bumped from time to time (with a policy like never closes to the latest release than 2 release).

Discussed in #146

bare-trait-objects, unused-extern-crates, ellipsis-inclusive-range-patterns, elided-lifetimes-in-paths, explicit-outlives-requirements

Only warn(rust_2018_idioms) and deny(unsafe_op_in_unsafe_fn) would actually require code changes.

Actually deny(missing_docs) too.

RELEASE:
libseccomp: v0.2.3
libseccomp-sys: v0.2.1

TODO:

• Solve all PRs and issues in https://github.com/libseccomp-rs/libseccomp-rs/milestone/2
• Validate the crate documentation
  • Run cargo doc --no-deps
• Change Cargo.toml/README.md/CHANGELOG.md for v.0.2.3
• Create v0.2.3 tag
• Publish the libseccomp crate on crates.io
• Create the release page in GitHub

Is your feature request related to a problem? Please describe.

ScmpNotifResp has (logical) invariants you need to manage by hand.

If you specify SECCOMP_USER_NOTIF_FLAG_CONTINUE, error and val must be 0.
If error != 0, val is ignored.

Describe the solution you'd like

Functions to construct a ScmpNotifResp for all responds kind (spoofed success, spoofed errorm continue):

impl ScmpNotifResp {
    fn new_val(id, val: i64) -> Self;
    fn new_error(id, error: i32) -> Self;
    fn new_continue(id) -> Self;
}

Describe alternatives you've considered

N/A

Additional context

N/A

The socket family is the first arg, not second. Thus the check should be $arg0 != AF_UNIX.

SeccompErrno contains all errnos returned by the libseccomp api. However if you set ApiSysRawRc the errno from the kernel seccomp api is returned instead. This raises to problems

1. The descriptions of the errno are not (always) correct.
2. The kernel seccomp api can return errnos which are not returned by the libseccomp api.

1. Can be ignored IMHO because if you set ApiSysRawRc you are interested in the errno and perform your own handling of it instead of logging it (and die). Also it's limited what we can do. However 2. is problematic if you want to match on an errno which is not covered by SeccompErrno.
Looking at the manpage of seccomp(2) list only EBUSY as not covered errno.

libseccomp next major (2.6)

• New functions
  • seccomp_export_bpf_mem (#121)
    • New errno: -ERANGE, returned by seccomp_export_bpf_mem (relevant for SeccompErrno)
  • seccomp_precompute (seccomp/libseccomp@e797591) (#220)
  • seccomp filter transactions (seccomp/libseccomp#415)
    • seccomp_transaction_start
    • seccomp_transaction_commit
    • seccomp_transaction_reject
• New architectures (relevant for ScmpArch and feature:const-syscall):
  • sheb
  • sh
  • loongarch64 (seccomp/libseccomp@7179ff3)
  • m68k (seccomp/libseccomp@dd5c9c2)
• New syscalls:
  • Linux 6.2 (for m68k): atomic_barrier, atomic_cmpxchg_32, getpagesize
• Misc
  • seccomp_notify_fd can return -1 and -EINVAL (manpage only change?)
  • SCMP_FLTATR_CTL_WAITKILL (seccomp/libseccomp@9698996; seccomp/libseccomp#387) (#237)

libseccomp next minor (2.5.5)

libseccomp v2.5.4

• New syscalls:
  • Linux 5.17: futex_waitv, set_mempolicy_home_node (#175)

Change type of ScmpNotifData.syscall to ScmpSyscall.

The the time we require rust >1.56 we can switch to the 2021 edition.

io_safety (#166) will requires rust 1.63.

A snippet like

let mut ctx = ScmpFilterContext::new_filter(ScmpAction::Allow)?;
ctx.add_rule(
    ScmpAction::Allow,
    ScmpSyscall::from_name("openat")?,
)?;

will show

Error: Error { kind: Errno(-13), source: None, message: "Setting the attribute with the given value is not allowed" }

because of

seccomp_rule_add(3):

-EACCCES
The rule conflicts with the filter (for example, the rule action equals the default action of the filter).

I'd like to add @rusty-snake as a maintainer who is one of the most active contributors, thanks for your contributions!
Please create a PR to update the MAINTAINERS file :)
Format: name <e-mail address> (@GitHub ID)

Currently this is a very common pattern in libseccomp-rs:

let ret = unsafe { seccomp_foo() };
if ret != 0 {
    return Err(SeccompError::new(Errno(ret)));
}
// use ret

I want this to refactor to somewhat like

let foo = unsafe { ensure_zero!(seccomp_foo()) };
// use foo (which has is better name than ret)

We should add the following two syscalls to our syscall database for the const-syscall feature.
These syscalls are available in libseccomp v2.5.4.

• futex_waitv
• set_mempolicy_home_node

Ref. seccomp/libseccomp@2657109

RELEASE:
libseccomp: v0.2.2

TODO:

• Merge Make the notify module visible in the docs #78 into main branch
• Validate the crate documentation
• Change Cargo.toml/README.md/CHANGELOG.md for v.0.2.2
• Create v0.2.2 tag
• Publish the crates on crates.io
  • Run cargo doc --no-deps
• Create the release page in Github

Currently notify_id_valid returns Result<(), SeccompError> or more precise it returns Ok(()) if the id is valid or Err(SeccompError::new(Errno(ENOENT))) if it is not valid.

This results in code like this:

if notify_id_valid(fd, req.id).is_err() {
    // abort ...
}

IMHO it would be cleaner if the API would look like

if !notify_id_valid(fd, req.id) {
    // abort ...
}

Needs documentation:

• ScmpArgCompare::new
  • What is arg? The "argth" argument of the syscall.
  • Does counting start at 0? Yes.
  • When is datum_b used? Masked Eq AFAICTY
• ScmpData removed
  • OT: Does this need to be pub or at least #[doc(hidden)]? It does not seem to be used anywhere.
• ScmpAction::to_native private
• ScmpArch::to_native private
• ScmpCompareOp::to_native private
• ScmpFilterAttr::to_native private

Other documentation notes:

• Highlight ScmpFilterContext somehow to make clear that this is the "main-type" of this crate new users should look at.
• Use more examples. They will also add better coverage.
• How do I set ScmpFilterAttr? With set_filter_attr. Add examples and link to it.
• ScmpFilterAttr::CtlOptimize
  • Which levels are available
• ScmpCompareOp::MaskedEqual
  • What is masked equality? How does it work?
• ScmpAction::from_str
  • Which string are supported as input? Add an example.
    • kill? No.
    • SCMP_ACT_KILL? Yes.

Discussed in #163

use std::error::Error as StdError;
use crate::{
    notify_id_valid, Result, ScmpArch, ScmpFd, ScmpNotifReq, ScmpNotifResp, ScmpSyscall,
    NOTIF_FLAG_CONTINUE,
};

//#[derive(Debug)]
pub struct Rotify {
    fd: ScmpFd,
    actions: Vec<RotifAction>, // ignore this filed for now
}

impl Rotify {
    pub fn receive(&self) -> Result<RotifReq> {
        let req = ScmpNotifReq::receive(self.fd)?;
        Ok(RotifReq {
            id: RotifCookie(req.id, self.fd),
            pid: RotifPid(req.pid),
            data: RotifData {
                syscall: req.data.syscall,
                arch: req.data.arch,
                instr_pointer: req.data.instr_pointer,
                args: req.data.args,
            },
        })
    }

    // or send_response()?
    pub fn respond(&self, id: RotifCookie, resp: RotifResp) -> Result<()> {
        match resp {
            RotifResp::Continue => ScmpNotifResp::new(id.0, 0, 0, NOTIF_FLAG_CONTINUE),
            RotifResp::Val(val) => ScmpNotifResp::new(id.0, val as i64, 0, 0),
            RotifResp::Error(error) => ScmpNotifResp::new(id.0, 0, -(error as i32), 0),
        }
        .respond(self.fd)
    }
}

#[derive(Debug)]
#[non_exhaustive]
pub enum RotifResp {
    Continue,
    Val(i64),   // Are negative values supported? If not change this to u32.
    Error(u16), // u16 -> i32 -> *= -1
}

#[derive(Debug)]
#[non_exhaustive]
pub struct RotifReq {
    pub id: RotifCookie,
    pub pid: RotifPid,
    pub data: RotifData,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct RotifCookie(u64, ScmpFd);
impl RotifCookie {
    pub fn is_valid(&self) -> bool {
        notify_id_valid(self.1, self.0).is_ok()
    }

    pub fn ensure_valid(&self) -> std::result::Result<(), &str> {
        if self.is_valid() {
            Ok(())
        } else {
            Err("This notification id has been invalidated.")
        }
    }
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct RotifPid(u32);
/*
impl RotifPid {
    fn helper_functions_like() -> File {
        let mem = File::open(&format!("/proc/{}/mem", self.0))?;
        self.id.is_valid().then(|| Some(mem))
    }
}
*/
// PartialEq<u32>; From<u32>; Into<u32>

#[derive(Debug)]
pub struct RotifData {
    pub syscall: ScmpSyscall,
    pub arch: ScmpArch,
    pub instr_pointer: u64,
    pub args: [u64; 6],
}

impl Rotify {
    // todo: cancelable
    pub fn receive_and_handle_loop<F>(&self, mut handle_error: F)
    where
        F: FnMut(&mut dyn StdError)
    {
        loop {
            if let Err(mut err) = self.receive_and_handle() {
                handle_error(&mut err);
            }
        }
    }
    
    fn receive_and_handle(&self) -> Result<()> {
        let req = self.receive()?;
        for action in &self.actions {
            if action.should_handle(&req) {
                if let Some(resp) = (action.func)(&req) {
                    self.respond(req.id, resp)?;
                }
            }
        }

        Ok(())
    }

    pub fn add_action<T, F>(&mut self, filter: Option<T>, f: F) -> &mut Self
    where
        //T: RotifFilter + 'static,
        T: Into<Box<dyn RotifFilter>>,
        F: Fn(&RotifReq) -> Option<RotifResp> + 'static,
    {
        self.actions.push(RotifAction {
            //filter: filter.map(|fltr| Box::new(fltr) as _),
            filter: filter.map(Into::into),
            func: Box::new(f),
        });
        self
    }
}

//#[derive(Debug)]
pub struct RotifAction {
    filter: Option<Box<dyn RotifFilter>>,
    func: Box<dyn Fn(&RotifReq) -> Option<RotifResp>>,
}
impl RotifAction {
    fn should_handle(&self, req: &RotifReq) -> bool {
        if let Some(filter) = &self.filter {
            filter.should_handle(req)
        } else {
            true
        }
    }
}

pub trait RotifFilter {
    fn should_handle(&self, req: &RotifReq) -> bool;
}
impl RotifFilter for ScmpSyscall {
    fn should_handle(&self, req: &RotifReq) -> bool {
        *self == req.data.syscall
    }
}
impl RotifFilter for &[ScmpSyscall] {
    fn should_handle(&self, req: &RotifReq) -> bool {
        self.contains(&req.data.syscall)
    }
}
impl<F> RotifFilter for F
where
    F: Fn(&RotifReq) -> bool,
{
    fn should_handle(&self, req: &RotifReq) -> bool {
        (self)(req)
    }
}

• io_safety
• #152