Hide Forgot
Description of problem: Found this in journal log at warning level May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@aio May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@chown May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@clock May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@ipc May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@keyring May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@memlock May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@resources May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@sync May 03 17:23:15 mybox systemd[1]: /usr/lib/systemd/system/arpwatch.service:22: Failed to parse system call, ignoring: ~@timer Version-Release number of selected component (if applicable): arpwatch-3.1-12.fc34.x86_64
Thanks. It looks like my downstream sandboxing configuration in the service file is not quite tailored to the current version of systemd. I’ll look into it shortly.
Maybe you need to separate the allow list and the deny list in this way: SystemCallFilter=@system-service SystemCallFilter=~@aio @chown @clock @ipc @keyring @memlock @resources @sync @timer The manual systemd.exec says: "If the first character of the list is "~", the effect is inverted" That is the "~" is the first character after "=" and applies to the entire list. You might want to ask the systemd developers if this is true.
That’s what I concluded yesterday, too. Based on documentation, and validated by testing, I arrived at the same syntax you suggested. I hadn’t gotten the update pushed for Fedora 34 yet, though. I’ll do that next. Thanks again for your very helpful feedback.
FEDORA-2021-65cde10eeb has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-65cde10eeb
FEDORA-2021-65cde10eeb has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-65cde10eeb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-65cde10eeb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.