Given this service already uses DynamicUser I'm not sure how much value specifying this option to darkhttpd will add. If you instead used systemd to achieve the isolation you desire I think that would be more valuable for this service.

Are you familiar with systemd sandboxing/isolation options?

Given this service already uses DynamicUser I'm not sure how much value specifying this option to darkhttpd will add. If you instead used systemd to achieve the isolation you desire I think that would be more valuable for this service.

Is there any benefit of exposing systemd's sandboxing and darkhttpd's built-in chroot in the service api as options?

Depends how much systemd kool-aid you've drank. Seems like a redundant set of options to me, but then again I've drank quite a bit of systemd kool-aid...

@aanderse Thank you for your reply!

Some thoughts:

Depends how much systemd kool-aid you've drank.

If the implementation is different or doesn't use systemd then it might not seem redundant for the kool-aid abstainers. I'd prefer to have the choice and I think adding this feature would only introduce a trivial amount of code to the darkhttpd service definition.

Seems like a redundant set of options to me, but then again I've drank quite a bit of systemd kool-aid...

A different implementation of the same thing is not necessarily redundant in my eyes but pragmatists may object. Additionally, it would make the darkhttpd service API a bit more complete/comprehensive.

If in the future NixOS decides to support an alternative init system (sounds like that might not happen for a very long time) that does not bundle a sandboxing feature then the darkhttpd chroot option might already be somewhat ready to go with providing that option or at the very least (given nobody ever cares to use the darkhttpd chroot option and always favor the systemd service over the native option) serve as documentation of a comprehensive api for darkhttpd.

What do you think? Could we have both? What do other people in the nix community think? I don't mind opening it up for further discussion on the discourse if we'd like to weigh the pros and cons and think through it more.

@80aff123-9163-4f3e-a93d-4a2f35af9be1 no problem - I wouldn't stand in the way of someone adding some flexibility to this module 😄. We could ping the module author if you are keen on proceeding and I'm pretty sure they would be happy to accept a change like that 👍

The obstacle this PR has, though, is that I don't believe this would even work as-is. You need capabilities to call chroot, which darkhttpd tries to do if the --chroot flag is passed. Did you test this?

The obstacle this PR has, though, is that I don't believe this would even work as-is. You need capabilities to call chroot, which darkhttpd tries to do if the --chroot flag is passed.

@aanderse Thanks! Could you give an example of what would be needed to add the capabilities?

Did you test this?

It looks like the pull request branch from @80aff123-9163-4f3e-a93d-4a2f35af9be1 was deleted.

We could ping the module author if you are keen on proceeding and I'm pretty sure they would be happy to accept a change like that

@bobvanderlinden What are your thoughts on adding this feature to the darkhttpd service module?

@peterhoeg is the module author I believe.

You need to add CAP_SYS_CHROOT to AmbientCapabilities, conditional on the chroot option being set of course.

@peterhoeg is the module author I believe.

@aanderse Thanks for catching that. I confused the package maintainer with the service module author.

You need to add CAP_SYS_CHROOT to AmbientCapabilities, conditional on the chroot option being set of course.

Thanks! I found two extant examples of AmbientCapabilities and CAP_SYS_CHROOT being set in nixpkgs in case anyone would like to take a look. Below are the links for convenience:

1. unbound service

2. icecream service

I'd be happy to make a pull request with the additions for code review after @peterhoeg advises.

I marked this as stale due to inactivity. → More info