audit: 4.1.1-unstable-2025-08-01 -> 4.1.2, cleanup

[LordGrimmauld]

• Release Notes for 4.1.2: https://github.com/linux-audit/audit-userspace/releases/tag/v4.1.2
• the default audisp socket path was changed, so the default in nix was adjusted accordingly. This allows removing the dependency on systemd-tmpfiles-setup.service
• adjusted the audit test to look for the new socket path
• adjusted opensnitch to use the new socket path
• set doCheck = true (required patching a #! /usr/bin/env shebang)
• disabled static build by default (was enabled to allow tests of audit internals to build, but these will now automatically be disabled if static is disabled, thanks to a patch upstream)
• enabled python bindings on cross, disabled them on static (makes little sense, wouldn't be importable)
• added audit to the python package set so it can be imported on all python3 versions
• cleaned up passthru tests
• added pythonImportsCheckHook

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • aarch64-linux (cross)
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[LordGrimmauld]

I still need to run testing on this, but i made use of the upstream unit, switched to unstable instead of patch, and cleaned up the opensnitch socket path stuff.

[LordGrimmauld]

VM and passthru tests all passed on x86_64-linux, running some final tests on aarch64 (opensnitch VM test is known-broken there, on master too) but this looks about ready now

[LordGrimmauld]

I also opened two PRs upstream to hopefully drop some of the patches done here:
linux-audit/audit-userspace#500
linux-audit/audit-userspace#501

[nikstur]

I'm not convinced that it is a particularly good idea to rely more on upstream:

1. I find the upstream service weird/inferior: why is it set to Type=forking? Type=simple is much better and what the systemd docs suggest to use whenever possible: https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#PIDFile=
2. What we currently do to load the rules is superior to augenrules: (a) it's not a script (b) augenrules does something we do not need on NixOS and putting things into /etc is a hack that makes our boot process needlessly bloated. By introducing augenrules we have an unnecessary dependency on bash for using the audit subsystem which I would like to avoid. I suggest we actually drop augenrules instead of trying to fix it.

[LordGrimmauld]

1. Type=simple is in the process of being deprecated. Type=exec might be an option, but imo that consideration should be moved upstream. As it stands, audit writes the pid file unconditionally, even if we do Type=simple: https://github.com/linux-audit/audit-userspace/blob/8ed522ae8ef3313d74b944fadd7d8cc01dc814dd/src/auditd.c#L882
   Further, @arianvp suggested switching to Type=forking and @ElvishJerricco followed up by suggesting to use the upstream unit (in systemd matrix room).
2. a) yes, and i kept that loading of rules. But augenrules was broken, so fixing it should be an improvement. And it may still be useful (in different context), happy to split it to a $scripts output if necessary (and delete the service we don't use from the package).
3. b) not quite. This PR does not actually make use of the augenrules-based audit-rules service. In fact we are setting systemd.services.audit-rules.enable = lib.mkDefault false; to disable that service.
4. About augenrules: augenrules as stand-alone script may still be useful. Not in its current form, but once I made it accept path arguments of where to load/put rules, it may be an interesting script to call not as part of a service, but as part of a nix file writer to generate/collect rules. Our current rule generation is limited in the fact it can only consume and write strings. This means any package providing rule files would inherently require IFD to build the complete audit rule set, and i would rather not rely on this inferior pattern.

[arianvp]

Auditd is implemented as a classic self-forking daemon and uses forking for readiness notification that audit logging is setup and working. The contract is that if you order after the audit service that audit logging is working.

With Type=exec and simple you dont get that guarantee

An alternative would be Type=notify but they don't have integration with sd_notify (at the moment).

[nikstur]

Sounds good. Thank you for taking the time to answer my concerns. I'm convinced.