I may be biased but the OpenBSD approach with pledge() and unveil() have been my favorite sandboxing mechanisms of all time due to their simplicity: pledge has really understood that as a developer I want to whitelist an intention, not a specific set of syscalls and options, and unveil is chroot on steroids <3
It's like Linux's RESOLVE_BENEATH flag to openat, except it's a constraint placed on the directory descriptor itself so that subsequent opens using openat(2) cannot reach anything outside the subtree. Which seems like exactly the semantics you'd want for a capability system. In FreeBSD Capsicum mode, this behavior is enforced implicitly[1], but it'd be a nice thing to have explicitly to help incrementally improve code safety.
Seems FreeBSD beat OpenBSD to the punch with something similar, FD_RESOLVE_BENEATH, committed only a couple of weeks ago.[1] Seems the idea was conceived before the OpenBSD proposal, and it differs subtly by attaching to the file descriptor rather than the file description (aka file table entry), though unlike the other file descriptor flags (FD_CLOEXEC, FD_CLOFORK) it's hacked to be inherited across dup, behaving more like file table entry flags (access mode, O_NONBLOCK, etc).
We will publish a comparison but I'm cautious as it can easily look like an attack over what others do and I feel strongly about not being hostile to other open-source projects :-)
Long story short: we provide multi-source/multi-destination/multi-storage (ie: backup S3 to disk, restore to SFTP), we have a nice UI, we reimplemented our own database over CAS allowing us to have a virtual filesystem + a ton of nice features on top of the snapshots, + an archive format of our own and other nice features.
All of this is in the free version, what's going to be paid is plugins to backup commercial services, enterprise features like multi-user support, ACLs, or compliance related features (ie: GDPR / sensitive data detection, ...), backup orchestration over a pool of machines, and more.
Thanks for replying. Maybe I misunderstood something. The way I saw it, I can not use plakar without having to install Go first (the dependency). And that bothers me a bit.
Let me explain my reasoning. Suppose I made an .ptar archive today, put it on a USB stick, threw that in a vault and forgot about it. Ten years down the road I want to restore that archive. But the .ptar file alone is useless without the plakar tool. So I have to install plakar first. Ideally plakar should sit on that USB stick, right next to the archive, ready to be installed. But plakar is dependent on Go, so I have to hunt Go first. And who knows what the state of Go will be ten years down the road. The .ptar file that I made today may end up unusable ten years later, because Go evolved in some unpredictable way.
first, we're going to release pre-built binaries for various platforms with our next stable release which will remove the need to install a go runtime as you'll have a standalone native executable for plakar / ptar.
then, the format is open and we'll publish a friendlier documentation should someone want to implement their own builder/reader.
finally, it's likely we'll publish a library + standalone executable in C, so that people can easily implement a binding to their favourite language and/or have a small executable in a language that traverses the decades :-)
