the issue

Some sysctls, e.g. vfs.bufspace on FreeBSD, exaggerate their length, i.e. they report being a Long, but read returns only 4 bytes:

info = CtlInfo { ctl_type: Long, fmt: "L\u{0}", flags: 2147745799 }

Attempting to read these will cause a panic, as we are calling LittleEndian::read_u64 on a Vec with less than 8 bytes length.

thread 'main' panicked at 'assertion failed: 8 <= buf.len()', [redacted]/.cargo/registry/src/github.com-1ecc6299db9ec823/byteorder-1.2.3/src/lib.rs:2024:9

expected behaviour

On short reads, the value should be zero-padded to the size of the target value.

steps to reproduce

The following program will panic on FreeBSD

extern crate sysctl;

fn main() {
    let value = sysctl::value("vfs.bufspace");
    println!("vfs.bufspace: {:?}", value);
}

e.g. from the sysctl manpage:

         int i, mib[4];
           size_t len;
           struct kinfo_proc kp;

           /* Fill out the first three components of the mib */
           len = 4;
           sysctlnametomib("kern.proc.pid", mib, &len);

           /* Fetch and print entries for pid's < 100 */
           for (i = 0; i < 100; i++) {
                   mib[3] = i;
                   len = sizeof(kp);
                   if (sysctl(mib, 4, &kp, &len, NULL, 0) == -1)
                           perror("sysctl");
                   else if (len > 0)
                           printkproc(&kp);
           }

Hi,

First of all, thanks for this library. I'm very new to Rust so this might be a stupid question. I'm trying to read the "kern.cp_time" and "kern.cp_times" Ctl's on FreeBSD. This should be a list of long integers (user, nice, sys, intr, idle). sysctl-rs says it's a Long type value and the value I get is just one i64 value but sysctl kern.cp_time gives me the list of all 5 numbers. Could you point me the way on how to read all 5?

Thanks, Rudolph

Compile warning on Linux. Look into if we need a newer version of bitflags.

warning: use of deprecated macro `try`: use the `?` operator instead
  --> src/ctl_flags.rs:6:1
   |
6  | / bitflags! {
7  | |     pub struct CtlFlags : libc::c_uint {
8  | |         /// Allow reads of variable
9  | |         const RD = CTLFLAG_RD;
...  |
69 | |     }
70 | | }
   | |_^
   |
   = note: `#[warn(deprecated)]` on by default
   = note: this warning originates in the macro `__impl_bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)

using the Cargo.toml and example code from the README on openbsd i get the following:

% cargo run
   Compiling sysctl v0.5.4
error[E0433]: failed to resolve: maybe a missing crate `sys`?
  --> /home/MYUSER/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sysctl-0.5.4/src/lib.rs:77:9
   |
77 | pub use sys::ctl::*;
   |         ^^^ maybe a missing crate `sys`?
   |
   = help: consider adding `extern crate sys` to use the `sys` crate

error[E0433]: failed to resolve: maybe a missing crate `sys`?
  --> /home/MYUSER/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sysctl-0.5.4/src/lib.rs:78:9
   |
78 | pub use sys::ctl_iter::*;
   |         ^^^ maybe a missing crate `sys`?
   |
   = help: consider adding `extern crate sys` to use the `sys` crate

error[E0432]: unresolved imports `sys::ctl::*`, `sys::ctl_iter::*`
  --> /home/MYUSER/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sysctl-0.5.4/src/lib.rs:77:9
   |
77 | pub use sys::ctl::*;
   |         ^^^^^^^^^^^
78 | pub use sys::ctl_iter::*;
   |         ^^^^^^^^^^^^^^^^

Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `sysctl` (lib) due to 3 previous errors

adding target_os = "openbsd" to the lib where freebsd is ends up in a whole other errors and fails too.

On FreeBSD, the doctest for temperature handling is failing. I've tried to bisect this, but it seems to go back to the initial commit.

$ cargo test --doc
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling sysctl v0.1.4 (file:///root/sysctl-rs)
    Finished dev [unoptimized + debuginfo] target(s) in 1.49s
   Doc-tests sysctl

running 10 tests
test src/lib.rs - CtlValue (line 205) ... ignored
test src/lib.rs - Temperature (line 271) ... FAILED
test src/lib.rs - description (line 961) ... ok
test src/lib.rs -  (line 6) ... ok
test src/lib.rs -  (line 33) ... ok
test src/lib.rs - set_value (line 862) ... ok
test src/lib.rs - value (line 503) ... ok
test src/lib.rs - value_as (line 697) ... ok
test src/lib.rs - value_oid (line 531) ... ok
test src/lib.rs - value_oid_as (line 740) ... ok

failures:

failures:
    src/lib.rs - Temperature (line 271)

test result: FAILED. 8 passed

Using sysctl::Ctl::set_value_string on FreeBSD causes it to print "type String", which I guess was for debugging purposes. More specifically, this is caused by the line below:

Since I am using this is in another Rust crate, it would be nice if it did not print anything.

The sysctl security.mac.asp.active_rule_version returns wrong type (integer instead of long unsigned) which is causing tests to fail when the value wraps over to negative value.

sysctl -d security.mac.asp.active_rule_version reports LU as type. Maybe use descriptions as source for types instead of current method?

On the Mojave and High Sierra tests, Cirrus says "Auto-upgraded from mojave-base to catalina-base". I guess that means there's no point to testing on those older releases. Should we just test on Catalina alone?

FreeBSD's Capsicum facility is used to sandbox processes into a capability mode. Unable to access any global namespaces, their ability to harm the overall system is very limited. It's a terrific security feature. But the sysctl(3) functions do access global namespaces. So to use them in capability mode requires a helper: the Casper library. Once a process is in capability mode, it can use the cap_sysctl(3) facility to access sysctls. I originally attempted to implement cap_sysctl in a separate crate, but encountered difficulties. Basically, it's just way too complicated. Dealing with sysctls, as you know, requires lots of code to handle all the different data types. So instead of having a separate cap-sysctl-rs crate, I propose moving that functionality into here. If you agree, this is what I think we should do:

1. Add libcasper(3) bindings to libc, or create a separate libcasper-sys crate. I'll raise the issue with the libc team and see which they prefer.
2. Implement basic libcasper support within the capsicum-rs crate. I've already got a branch for this.
3. Add a private SysctlProvider trait to this crate with three methods: sysctlbyname, sysctl, and sysctlnametomib. Existing functions like unix::funcs::value_oid will gain a new argument, a &dyn SysctlProvider.
4. Create two implementors of this trait: NativeSysctlProvider and CasperSysctlProvider. The former will simply wrap the existing sysctl(3) functions. The latter will wrap cap_sysctl(3), and will also include methods to initialize the casper connection and configure limits.
5. Create a public CasperSysctl struct and implement the Sysctl trait for it. In order to preserve the existing API, the actual casper connection will have to be a global variable.
6. Optionally, gate all of this Casper stuff behind a feature flag. However, since Casper is only implemented on FreeBSD and all official FreeBSD releases have it, I don't think we need to add a feature flag .

What do you think? cc @dlrobertson .

#20 added a Cirrus CI config file. However, it isn't being used on the master branch. I think you probably never activated Cirrus on this repository. To do so, follow the instructions at https://cirrus-ci.org/guide/quick-start/ , but stop at "Post Installation".

It seems like it's necessary to repeat the rustdoc comments before the #[cfg(target_os = "macos")] macros.

The following will not generate any rustdoc documentation for foo on macos, and the docstest will not execute:

/// such docs, meny wow, amaze
///
/// # Example
/// ```
/// foo();
/// ```
#[cfg(not(target_os="macos"))]
fn foo() {
    println!("bar");
}

#[cfg(target_os="macos")]
fn foo() {
    println!("baz");
}

What's your opinion on providing a struct interface, maybe along the following lines:

extern crate sysctl;

fn main() {
    let kernversion: sysctl::Ctl = sysctl::Ctl::from_str("kern.osrevision");
    println!("Description: {:?}", kernversion.description());
    println!("Value: {:?}", kernversion.value());
    // etc...
}

This would set up the possibility of creating iterators over Ctls, e.g. for iterating through all children of a node.

I understand this would be a breaking API change, so it would probably require a major SemVer bump.

I would start drafting a PR for this.

I'd like to be able to access CtlInfo.fmt in some way and was wondering what would be the nicest way to expose it:

• publish struct CtlInfo and add a Ctl.info() method and add some methods to it (see #19)
• Add a Ctl.fmt() method to return the format string
  @johalun maybe you have some other ideas?

Because you need root access to do this. Hmm, can we tell cargo to ignore running this test?

Transmuting bytes to an arbitrary type can cause undefined behavior.

The safety requirements:

1. T must be Sized.
2. The length of bytes must be equal to size_of::<T>().
3. The alignment of bytes must be equal to align_of::<T>().
4. T must be valid for any binary representation.

having continuous integration would catch stuff like this ...

arguably they broke the sysctl API (changed mutability)

Hi, I have made a lot of modifications and simplifications based on this library, and added support for Linux systems. Although @johalun mentioned that he is doing some work in this area, I can't seem to wait any longer :)

If you are interested in this version of my revision, I would be happy to submit a PR.

https://github.com/ExodusVPN/exodus/tree/rewrite/crates/sysctl

https://github.com/ExodusVPN/exodus/blob/rewrite/crates/sysconfig/src/sysctl.rs