Btw. I think that the nix::sys::ptrace::ptrace function should be marked as unsafe. It allows to change arbitrary registers and addresses in a child process - just as dereferencing a pointer is unsafe in Rust.

I was unable to use libc::user_regs_struct, the Rust compiler complains that it can't find the members. By the way, we're missing PTRACE_GETREGS.

I tried to use the user_regs_struct in the following way:

extern crate libc;

fn main() {
    println!("{}", libc::user_regs_struct::rdx);
}

which bails out with

file: 'file:///home/marcin/proj/user_regs/src/main.rs'
severity: 'Error'
message: 'no associated item named `rdx` found for type `libc::user_regs_struct` in the current scope'
at: '4,22'
source: ''

This change adds support for the Fuchsia operating system to the nix crate. Fuchsia developers have a use case for nix, particularly its safe interfaces to the recvmsg(2) and sendmsg(2). Adding support requires:

• incrementing the libc dependency to 0.2.74
• conditionally not compiling nix functionality which depends on libc functionality that does not exist for Fuchsia

This PR closes #862.

Implemented functions:

• As User::query:
  • getpwnam
  • getpwuid
• As Group::query:
  • getgrgid
  • getgrnam
• As Users iterator:
  • getpwent
  • setpwent
  • endpwent
• As Groups iterator:
  • getgrent
  • setgrent
  • endgrent

~I wanted to implement getgrent, setgrent and endgrent, but they are missing from libc. (See https://github.com/rust-lang/libc/issues/923 )~

Integrates suggestions and comments made in #641. Basically we hid a lot of the internal workings of things and also revised the docs to make it more clear the exact API that nix is exposing.

There is a small amount of code cleanup I did in the macros. I also fixed the bad version of the ioctl! macro and also added a bad none version for use with no-data, hardcoded-number ioctls.

Would appreciate any and all feedback. Please especially fetch this code locally and generate the pretty docs for it (cargo doc --no-deps --open) so you can see what our users will see.

Closes #641. Closes #573.

cc @cmr @roblabla

Motivation is explained in #1602, new version allows to receive data without performing allocations inside the receive loop and to use received data without extra copying.

This pull request contains a breaking change to API recvmmsg (obviously) and also affects recvmsg - new version does not set length of control message buffer if one is passed. Later change can be avoided with a bit more copy-paste.

Fixes #1602

See discussion on https://github.com/nix-rust/nix/pull/528. This PR is to track the final decision of whether we are ready to merge the new CI infrastructure (and related bug fixes) back into master. Initially, we know that the branch is not ready to merge (as there are still failing tests).

This PR acts as a single point of reference to get the current status of how close we are to merging things back into master. A number of issues with "TRUST CI" in the title have been created for the work that appears to be required to get us to the point where this branch can be merged.

Some ptrace functions return structures through the data argument. This commit adds utilities to return data through this mechanism and function specialisations for a few of these functions (getting event messages or the siginfo_t struct). Once the next version of libc is released these utilities will be expanded to include the fpregs and user_regs structs.

Due to the need to use unsafe blocks to utilise these ptrace features I feel these are good candidates for inclusion into rust-nix

Some things are not implemented yet in redox, so a lot of annotations were added to remove functions when compiling for redox. Those functions will hopefully be added in time, but for now it's better to have partial support than none.

Blocked by https://github.com/rust-lang/libc/pull/1438

This adds support for calling reboot(2) on Linux (useful for implementing PID 1!).

• Testing: I can't imagine how this could be tested other than manually, which is what I did to ensure it works.
• libc: for some reason libc includes neither reboot() function, nor RB_* constants, so I had to hack-define them here. Should I open a bug/PR against the libc crate?
• API: I went with reboot() function for restarting, powering off, halting, etc. and an additional set_cad_enabled() function for enabling/disabling Ctrl-Alt-Delete, which still corresponds to reboot() C call, but has different semantics and return type. (But I'm open to suggestions here -- maybe it would be better to separate each action into its own function, i.e. restart(), poweroff(), halt()?)
• Documentation: I see most of the things in nix are undocumented, so I didn't document anything except for the set_cad_enabled() function, which obviously uses a non-standard name.
• Portability: I implemented the Linux version as I'm not familiar with anything else, but there surely are others (ex. BSD). If I didn't mess up anything, the new code is only compiled on Linux/Android, so it should be straightforward to implement the other versions too.

While I don't mind "*nix" to denote Unix (and Unix-like) systems, "Nix" specifically is taken by the "purely functional package manager". This could get worse in the future, because of how cargo fits almost perfectly with the Nix model, and I have seen integration prototypes already. You might have to deal with crates.io packages that interact with Nix, or even fully reimplement it in Rust.

I know it doesn't sound as cool, but what about "posix.rs" or some variation thereof?

Here's a first attempt at a rustian interface for getifaddrs, please review.

Changes for the changelog:

• Added nix::ifaddrs::{getifaddrs, InterfaceAddressIterator, InterfaceAddress and InterfaceFlags}

Closes #650. Closes #764.

The Linux armv7 uclibceabihf CI target is failing in multiple unrelated PRs e.g.:

• https://github.com/nix-rust/nix/pull/1948/checks?check_run_id=10378264392
• https://github.com/nix-rust/nix/pull/1945/checks?check_run_id=10378274766
• https://github.com/nix-rust/nix/pull/1947/checks?check_run_id=10378270076

With

$TOOL +$TOOLCHAIN clippy $ZFLAGS --target $TARGET --all-targets -- -D warnings
    Checking nix v0.26.1 (/tmp/cirrus-ci-build)
error: argument to `std::mem::size_of_val()` is a reference to a reference
    --> src/sys/socket/mod.rs:1295:17
     |
1295 |                 mem::size_of_val(&iv) + iv.len()
     |                 ^^^^^^^^^^^^^^^^^^^^^
     |
     = help: dereference the argument to `std::mem::size_of_val()` to get the size of the value instead of the size of the reference-type
     = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#size_of_ref
     = note: `-D clippy::size-of-ref` implied by `-D warnings`

error: argument to `std::mem::size_of_val()` is a reference to a reference
    --> src/sys/socket/mod.rs:1295:17
     |
1295 |                 mem::size_of_val(&iv) + iv.len()
     |                 ^^^^^^^^^^^^^^^^^^^^^
     |
     = help: dereference the argument to `std::mem::size_of_val()` to get the size of the value instead of the size of the reference-type
     = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#size_of_ref
note: the lint level is defined here
    --> src/lib.rs:46:24
     |
46   | #![cfg_attr(test, deny(warnings))]
     |                        ^^^^^^^^
     = note: `#[deny(clippy::size_of_ref)]` implied by `#[deny(warnings)]`

error: could not compile `nix` due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `nix` due to previous error

Exit status: 101

For a UDP server program, it is very useful to use sendmmsg() and recvmmsg() to improve the performance by reducing syscalls.

And it is not a uncommon setup that a single socket can receive IP packets with difference destination addresses. In this type of setup, we obtain the real destination addresses of messages from the Ipv4PacketInfo/Ipv6PacketInfo control message when using recvmmsg(). Corresponding to that, Ipv4PacketInfo/Ipv6PacketInfo control messages are used to set source addresss when sending out multiple messages at once via sendmmsg().

In the breaking change introduced by 0.26 about sendmmsg() api (#1744), it seems it was assumed that control messages are shared/same across all the messages in the batch, I think this is a false assumption.

Did I read the code wrong? If so, is there any example of how to use the new API correctly in this use case.

Hi,

I try to implement a raw socket to be able to fetch all (sent/received) IP packets through a given network interface. For this I would like to use libc::IPPROTO_IP, but it does not seem to be available in SockProtocol.

I try to do the following (obviously nix::sys::socket::SockProtocol::IpProtoIp does not exist)

  let fd = match nix::sys::socket::socket(
            nix::sys::socket::AddressFamily::Packet,
            nix::sys::socket::SockType::Raw,
            nix::sys::socket::SockFlag::SOCK_NONBLOCK,
            nix::sys::socket::SockProtocol::IpProtoIp,
        ) {
            Err(err) => return Err(format!("Error: {}", err).to_string()),
            Ok(fd) => fd,
        };

        // attach to device
        match nix::sys::socket::setsockopt(
            fd,
            nix::sys::socket::sockopt::BindToDevice,
            &OsString::from(&iface.to_string()),
        ) {
            Ok(()) => (),
            Err(err) => return Err(format!("Error: {}", err).to_string()),
        };

Is there a workaround to add a protocol not supported by nix::sys::socket::SockProtocol?

Thanks.

The following segfaults just as it gets out of libc::setcontext -> libc::getcontext, after printing "Run" just once (latest arch on x86_64):

use nix::ucontext::UContext;

fn main() {
    let v = vec![1, 2, 3];
    let ctx = UContext::get().unwrap();
    println!("Run");
    std::mem::drop(v);
    ctx.set().unwrap();
}

Considering that it seems to restore the stack pointer and registries without any information about what has happened to the referred variables in the meantime I don't find it surprising... Or do I not understand what UContext is supposed to do at all?

How is this supposed to be used/to work? Doesn't the set miss being marked unsafe and extensive explanation on what would make its usage correct?

NB: This also segfaults:

use nix::ucontext::UContext;

fn main() {
    let ctx = UContext::get().unwrap();
    println!("Run");
    ctx.set().unwrap();
}

but even if that turned into an infinite loop I wouldn't consider the behavior correct unless something reasonable happens to the first example as well...

Adds release-please automation.

• release-please: Automatically updates the SemVer version, creates a PR for each release (people don't need to manually edit the changelog) when merged adds the release tag. This can be expanded to incorporate other functionality later (e.g. publishing to crates.io).
• gitlint: Enforce conventional commits required by release-please

See https://github.com/JonathanWoollett-Light/nix/pull/1