Re: automatic creation of a chroot environment

On 7/16/26 05:45, Rozhuk Ivan wrote:
> On Thu, 16 Jul 2026 09:09:01 +0200
> vermaden <[email protected]> wrote:
> 
>>> I've been using chroot for a long time to reduce
>>> the risk of web application hacking on my server.
>>>
>>> https://github.com/rozhuk-im/chroot_env  
>>
>> Thank You for sharing, I will add this to next VN.
>>
>> Two questions out of curiosity ...
>>
>> 1. How is that better then 'Service Jails'?
>>
>> 2. How is that better then 'Single Process Jails'?
>>
>> https://vermaden.wordpress.com/2023/06/28/freebsd-jails-containers/#single-process-jails
>>
> 
> This isn't better than Jails, it's a bit different.
> 
> As a solution, the script doesn't rely on jails or zfs, but instead uses tmpfs and chroot.

(My wording tied specifically to the later "rework" note's context:)

Most of the systems that I build software on via use of
poudriere(-devel) make no use of ZFS anywhere. poudriere(-devel) can use
ZFS and some of its features but does not need to. poudriere(-devel)
does use jails. I do have access to one build system that uses ZFS
instead of UFS.

Going in a different direction . . .

If one tries to build, for example, lang/rust using a tmpfs file system,
there needs to be enough RAM+SWAP to allow something like 30 GiBytes for
the tmpfs to use just for lang/rust materials in that RAM+SWAP --plus
space for other stuff not specific to lang/rust.

> There's no network stack or OS kernel isolation.
> This solution can be used to run a browser on a workstation, so even if someone were able to download and run the code automatically, it likely wouldn't launch (due to noexec and nosuid). And if it did launch, there's nothing valuable in the isolated environment.
> 
> The general idea is that if an application is hacked, there's no way to write files, and nothing can be run where files can be written. Even if it's possible to run something from the existing environment, almost nothing is available. Only the application's own data for reading and writing, and temporary files, are accessible.
> At the same time, the overhead of maintaining the solution is minimal: in my setup, it's enough to update ports and restart services; the script will automatically recreate the chroot with all the files needed for launching.
> 
> Currently, everything is stored in tmpfs, but this can easily be changed to geom md + UFS2 image.

The md+UFS2 context is analogous to the tmpfs for needing to be able to
hold something like 30 GiBytes+ for lang/rust materials --plus space for
other stuff not specific to lang/rust.

> In chroot, almost everything is mounted in RO, unlike in jails, where everything looks like a regular installation.
> 
> You can adapt this script for your own purposes to create an environment with all dependencies.
> In your blog, you used /rescue/sh. The examples include examples/sh - the script will automatically copy everything needed to /bin/sh.
> 
> 
> 
> PS: I wanted to rework portmaster/ports make so that it would build packages like poudriere in a clean environment, but without requiring zfs and complex management.

poudriere(-devel) has separate clean environments for each port-package
built, not just one for the overall sequence for one bulk command (vs.
the live boot system). poudriere(-devel) bulk builds never run into
conflicts with ports/packages that are not being used for the specific
one being built at the time in a builder (assuming no unnecessary
dependencies have been created).

The goals:

) protect the live system from changes
vs.
) avoid port/port-package conflicts as well

are very different. Which/what scope and type of "clean" are you
referencing for your rework effort?

As noted earlier: poudriere(-devel) does not require ZFS to be involved.

poudriere(-devel) tries to be appropriate for building 35000+
port-packages in one bulk command, from small resource use port-package
examples being involved through the biggest resource use port-package
examples being involved. (This is while allowing a degree of parallel
port-package builds and parallel make jobs in a port-package build.)
Certainly not a trivial target for what to support.


-- 
===
Mark Millard
marklmi at yahoo.com