At the moment we just exclude the following variables from the params method, as we are unable to restore this:

Attemting to set these results in a JailSetError("osrelease cannot be changed after creation").

We cannot set these, as we first start the jail, and then later on set all the parameters:

It would probably be a good idea to just create a big HashMap of values, and pass that into jail_create.

Hi - Thanks for the library kind of cool that so many freebsd primatives are coming to Rust.
I was testing out building a readonly jail using an fstab definition on my system.

.param("mount.fstab", param::Value::String("/etc/fstab.rojail".to_string()))

I got

thread 'main' panicked at 'could not start jail: JailSetError("unknown parameter: mount.fstab")', src/libcore/result.rs:1009:5

Looking at jail(8) I see it's a pseudo-parameter so I wasn't too surprised but thought I would raise this if you start to prioritize them.

It would be great to serialize the configuration of a StoppedJail into JSON, YAML, TOML, etc. in a as sane as possible way.

as soon as the TryFrom and TryInto traits are stabilized, implement:

impl TryFrom<StoppedJail> for RunningJail {
    fn from(stopped) -> Result<RunningJail, JailError> {
        stopped.start()
    }
}

and vice versa:

impl TryFrom<RunningJail> for StoppedJail {
    fn from(running) -> Result<StoppedJail, JailError> {
        running.stop()
    }
}

Import the rctl(8) code from phyber/jail_exporter. I guess the API could be something along the lines of:

fn RunningJail::resource_usage(&self) -> Result<HashMap<String,i64>,JailError>

If RCTL/RACCT are unavailable or disabled, an appropriate JailError should be returned.

Testing with nested Jails has brought up some bugs:

• At the moment, BuildBot builds are failing because we seem to be handling nested jails things rather flakily - namely we're setting properties that we aren't allowed to in the tests.

  • We should conditionally disable these in the tests.

• RCTL doesn't work in Jails (#22):

  • as of version 0.0.3 of rctl, (#23), the status check reports an invalid kernel state when attempting to use RCTL inside a jail.
  • this broke jail teardown (#24)

At the moment the only way to get a parameter type is calling param on a RunningJail and then getting the type from that:

use jail::param::Type;

let param = running.param("osrelease").unwrap();
let param_type: Type = param.into();

assert_eq!(param_type, Type::String);

It would be great if we could get the type for a parameter without requiring a RunningJail:

use jail::param::Type;
let param_type = Type::of_param("osrelease");

assert_eq!(param_type, Type::String);

This would allow refactoring the huge match in param::get to actually match on the param::Type instead of the sysctl::CtlType, and outsource the handling of the different CtlType::Struct cases:

term is looking for a new maintainer

The author of the term crate does not have time to maintain it and is looking
for a new maintainer.

Some maintained alternatives you can potentially switch to instead, depending
on your needs:

• crossterm
• termcolor
• yansi

See advisory page for additional details.

We should probably not filter parameters at this time:

Like you, I setup a Buildbot server for my Rust projects to test on FreeBSD. But that takes $$$ and ongoing maintenance effort. Recently, https://cirrus-ci.com added a free FreeBSD build option. libc, nix, xattr, mio-aio, and tokio-file are already using it. It runs in a full VM, which is handy when testing jail-related code. You should check it out.

Most CI providers don't have FreeBSD around. We could however evaluate the following options:

Use a QEMU VM on Travis-CI

Advantages: have full control over image, are root, can build VIMAGE kernel, etc.
Disadvantages: PITA to maintain, and probably not the optimal performance.

Set up a dedicated Jenkins / Buildbot / Whatever

Advantages: full control
Disadvantages: running costs, responsibility for running untrusted code as a privileged user

Wait around until a wild FreeBSD-based CI appears

Advantages: least hassle
Disadvantages: Unclear if own kernel, root, can set RCTL rules, etc.

We could have Python bindings using rust-cpython. This would probably make @gronke happy because it allows libiocage to get rid of shelling out to jail(8) and overcome some of its limitations (e.g. only a single VNET device).

It would be great if we could someohow build an Iterator over all RunningJails that are present on the system.

dirs is unmaintained, use dirs-next instead

The dirs crate is not maintained any more;
use dirs-next instead.

See advisory page for additional details.

At the moment the CI fails on the RCTL step, as RCTL isn't allowed in jails:
https://buildbot.bsd.builders/#/builders/2/builds/24/steps/4/logs/stdio

We should probably:

• Check whether we are in a jail (security.jail.jailed) when probing for RCTL Support
• Fail gracefully when it isn't supported

Describe the bug

Inability to set uid of a jailed process.

To Reproduce
Consider the following use-case: I'm trying to change uid of a process running inside the jail.
For that purpose I use std::os::unix::process::CommandExt.uid.

In code:

let stopped_jail = StoppedJail::new(&path)
    .name("container 42")
    .param("vnet", Value::Int(1))
    .param("enforce_statfs", Value::Int(1))
    .unwrap();

Command::new(command)
    .jail(&jail)
    .uid(uid)
    .gid(gid)
    .spawn()
    .unwrap();

The spawn call returns EPERM error.

Expected behavior
The spawn call succeeds

Additional context
Underlying issue is jail_attach call. Per man page

The jail_attach() and jail_remove() system calls will fail if:

[EPERM] A user other than the super-user attempted to attach
to or remove a jail.

stdlib calls setuid here, before calling pre-exec hooks here. Since the process uid set to a non-priveleged user, alas, we fail.

Possible workarounds

Either

• Attempt to change stdlib (unrealistically)
• exec.jail_user. Well, not quite. It's not uid, not sure if it works for jail_attach.
• just create another hook to call setuid there!

WDYT?

Roadmap:

• fix current saving non-VNET jails (#34)
• add check whether VIMAGE is enabled, by checking whether kern.features.vimage sysctl exists and is set to 1 (c163a6a)
  • When johalun/sysctl-rs#21 is merged, use that.
• add support for E,jailsys tri-state parameters, and add handling for vnet parameter
  • Add type to enums (0bda407)
  • wait for johalun/sysctl-rs#19 to be merged or johalun/sysctl-rs#18 to be fixed some other way
  • Set a sane default (probably disable) & verify it works with VIMAGE disabled
  • verify no IP restrictions are set when vnet is not disable.
• Handle adding epairs / vnets to the jail
  • Add support for vnet to lib(private)ifconfig

failure is officially deprecated/unmaintained

The failure crate is officially end-of-life: it has been marked as deprecated
by the former maintainer, who has announced that there will be no updates or
maintenance work on it going forward.

The following are some suggested actively developed alternatives to switch to:

• anyhow
• eyre
• fehler
• snafu
• thiserror

See advisory page for additional details.

We should have some form of logging, probably using the log crate.

Describe the bug
Rust 1.35.0 has broken some things via what is described in rust-lang/rust#58952, meaning libjail-rs no longer compiles.

To Reproduce
Attempt to compile under Rust 1.35.0

Expected behavior
The crate compiles.

Additional context
I’m not sure if there is anything for libjail to do here, but I thought a tracking issue might be good.

At the moment we query a sysctl every time we read or write a property, to get the type and maximum size of the value. As these are unlikely to change during the lifetime of the library (should check whether they can be changed without rebooting), we can aggressively cache these.

JIDs can be set at start-time.