Is all this Docker encapsulation really required to "sandbox" chiadog?

[flotti455]

As much as I understand chiadog, it should only require read access to INFO-level debug.log and Internet connectivity.

Therefore, in order to encapsulate chiadog from doing any (thankfully / hopefully theoretical) malicious activity, shouldn't it already be enough to run chiadog as a Unix user with limited permissions, e.g. chiadog and setting up debug.log's Unix file permissions with a e.g. group chialog, which User chiadog is a member of?

[martomi]

I believe you're right and this would indeed be a simpler solution. At least I'm not aware of any way that a malicious script could circumvent the limitations based on user permissions.

Would you be interested in contributing a step-by-step guide to the README for users less familiar with the unix user permission system?

[Starttoaster]

I agree it's valuable to add instructions on using unix file permissions to sandbox Chiadog without Docker. But IMO it's more common to run services like these in Docker anyway these days, and the pattern for starting a docker container is more familiar to many. Especially to people that aren't Python devs.

[flotti455]

No, generally it's not more common to do such stuff in Docker these days.

Also keep in mind that Docker is a beast when it comes to using it on a Raspberry Pi farmer, a common thing.

[mhelsley]

Running it with systemd (e.g. systemctl --user) might be an option. systemd has a ton of sandbox-like settings (man systemd.exec)

If using systemctl with root/admin privileges you can dynamically allocate users to run services ( systemctl --system rather than systemctl --user) rather than have to manually do it. You can also filter system calls, hide home dirs, and there might even be a way to restrict it to only opening debug.log