Public bug reported: [ Impact ]
* Ubuntu Insights is not a user-facing application, so direct impact on the user is minimized. However, the bug fixed here is important for the developer side. * The upload systemd unit is presently nonfunctional due to a too restrictive sandboxing configuration, preventing Ubuntu Insights when run through this unit, from accessing the internet. This means that the reports are not properly being uploaded, even though the unit is periodically attempting uploads and the server listening for requests is functioning properly. Beyond the reports not being properly uploaded, this issue results in a periodic useless usage of system resources as the unit tries and fails to upload reports, though it is very minimal. [ Test Plan ] 1. Ensure consent is set, either via `ubuntu-insights consent -s=true` or ubuntu-insights consent -s=false`. 2. Generate a valid Ubuntu Insights report. For example, use `ubuntu-insights collect -f`. 3. Validate that the report was generated and is present in `~/.cache/ubuntu-insights/linux/local/`. 4. Rename the report generated to a Unix timestamp at least a full week earlier. - For example, `1665919002.json -> 1565919002.json` 5. With a working internet connection, upload the report using the upload systemd unit. Either wait for the weekly timer to trigger it or trigger it manually. - `systemctl --user start ubuntu-insights-upload.service` 6. Check the status and logs of the user systemd unit `ubuntu-insights-upload.service` to ensure that the unit ran successfully 7. Check that the report generated and renamed is no longer present in `~/.cache/ubuntu-insights/linux/local/`, and is instead present in `~/.cache/ubuntu-insights/linux/uploaded/` in some form. [ Where problems could occur ] * The upload unit's sandboxing is relaxed too much, to the point where it poses an undue risk. * The upload unit's sandboxing is not relaxed enough, resulting in the upload issue to persist. [ Other Info ] * As mentioned earlier, Ubuntu Insights is not a user-facing application. However, this issue breaks core functionality that the development team relies on for the collection of anonymized, consent- based telemetry on Ubuntu Desktop. Thus, though Questing is an interim release, an SRU is justified. * Related upload for Resolute (26.04): https://bugs.launchpad.net/ubuntu/+source/ubuntu-insights/+bug/2135266 * GitHub repository: https://github.com/ubuntu/ubuntu-insights ** Affects: ubuntu-insights (Ubuntu) Importance: Undecided Status: New ** Affects: ubuntu-insights (Ubuntu Questing) Importance: Undecided Status: New ** Also affects: ubuntu-insights (Ubuntu Questing) Importance: Undecided Status: New ** Merge proposal linked: https://code.launchpad.net/~kkuo/ubuntu/+source/ubuntu-insights/+git/ubuntu-insights/+merge/498026 ** Description changed: [ Impact ] * Ubuntu Insights is not a user-facing application, so direct impact on the user is minimized. However, the bug fixed here is important for the developer side. - *The upload systemd unit is presently nonfunctional due to a too + * The upload systemd unit is presently nonfunctional due to a too restrictive sandboxing configuration, preventing Ubuntu Insights when run through this unit, from accessing the internet. This means that the reports are not properly being uploaded, even though the unit is periodically attempting uploads and the server listening for requests is functioning properly. Beyond the reports not being properly uploaded, this issue results in a periodic useless usage of system resources as the unit tries and fails to upload reports, though it is very minimal. [ Test Plan ] * Upload Issue 1. Ensure consent is set, either via `ubuntu-insights consent -s=true` or ubuntu-insights consent -s=false`. 2. Generate a valid Ubuntu Insights report. For example, use `ubuntu-insights collect -f`. 3. Validate that the report was generated and is present in `~/.cache/ubuntu-insights/linux/local/`. 4. Rename the report generated to a Unix timestamp at least a full week earlier. - For example, `1665919002.json -> 1565919002.json` 5. With a working internet connection, upload the report using the upload systemd unit. Either wait for the weekly timer to trigger it or trigger it manually. - `systemctl --user start ubuntu-insights-upload.service` 6. Check the status and logs of the user systemd unit `ubuntu-insights-upload.service` to ensure that the unit ran successfully 7. Check that the report generated and renamed is no longer present in `~/.cache/ubuntu-insights/linux/local/`, and is instead present in `~/.cache/ubuntu-insights/linux/uploaded/` in some form. [ Where problems could occur ] * The upload unit's sandboxing is relaxed too much, to the point where it poses an undue risk. * The upload unit's sandboxing is not relaxed enough, resulting in the upload issue to persist. [ Other Info ] * As mentioned earlier, Ubuntu Insights is not a user-facing application. However, this issue breaks core functionality that the development team relies on for the collection of anonymized, consent- based telemetry on Ubuntu Desktop. Thus, though Questing is an interim release, an SRU is justified. * Related upload for Resolute (26.04): https://bugs.launchpad.net/ubuntu/+source/ubuntu-insights/+bug/2135266 * GitHub repository: https://github.com/ubuntu/ubuntu-insights ** Summary changed: - [SRU]: Broken upload unit + [SRU]: Upload unit blocked due to sandboxing -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2137587 Title: [SRU]: Upload unit blocked due to sandboxing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-insights/+bug/2137587/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
