In 4.4-1 (not shipped in Ubuntu), Debian enabled installation of an alternative 'restricted' systemd unit that is provided by upstream as an example. Among other things, this enables running chronyd with the -U (non-root) option.
While Debian lightly patched it to Debianize it, it lacks most of the changes Debian implemented for chrony.service, and indeed I'm a bit unsure how to get it to properly run in a Ubuntu LXD environment (I get errors regarding user credentials). So I get the sense this is going to need some additional attention to adapt and integrate it to make it officially supportable on Ubuntu.
Furthermore, I suspect some consideration to the use case for this could be beneficial. If nothing else, it should be documented somewhere why someone would prefer this vs. the standard chrony, and also how one would enable and configure it. The documentation should also make it clear for users who require strict security settings, what specifically this restriction provides. An autopkgtest case would not be out of place, as well. Does it make more sense to ship restriction functionality as a discrete systemd service (which will need to be maintained in parallel), or to provide a single unified systemd service configuration options to switch between restricted and regular?
In 4.4-1 (not shipped in Ubuntu), Debian enabled installation of an alternative 'restricted' systemd unit that is provided by upstream as an example. Among other things, this enables running chronyd with the -U (non-root) option.
While Debian lightly patched it to Debianize it, it lacks most of the changes Debian implemented for chrony.service, and indeed I'm a bit unsure how to get it to properly run in a Ubuntu LXD environment (I get errors regarding user credentials). So I get the sense this is going to need some additional attention to adapt and integrate it to make it officially supportable on Ubuntu.
Furthermore, I suspect some consideration to the use case for this could be beneficial. If nothing else, it should be documented somewhere why someone would prefer this vs. the standard chrony, and also how one would enable and configure it. The documentation should also make it clear for users who require strict security settings, what specifically this restriction provides. An autopkgtest case would not be out of place, as well. Does it make more sense to ship restriction functionality as a discrete systemd service (which will need to be maintained in parallel), or to provide a single unified systemd service configuration options to switch between restricted and regular?