let aaru = "aa-remove-unknown"; in
aaru tests whether /sys/kernel/security/apparmor/profiles can be opened.
Even though the file's permissions usually are 0444, open() still might
return `EPERM`, as this is a virtual filesystem. Thus, using `test -r`
doesn't suffice for this check.
What aaru does to solve this is (approximately)
if ! read … < /sys/kernel/security/apparmor/profiles; then
echo "Meh";
fi
In principal this works just fine. When looking closer, it doesn't
(which is the root cause of #273164). Careful readers will notice that
the actual access check (for `open()`) isn't actually related to the
`read` invocation, but the shell's input redirection, which works
totally fine:
If the file can't be opened, the shell will return an error and the test
fails. `read` won't even be invoked. The culprit is, the `read` shell
builtin might potentially jeopardize the *successful* test result
(`open()` succeeding): When no profiles are loaded, the file will be
empty and `read` will return 1 for `EOF`.
As the `if`'s command is only invoked after the actual test succeeded,
`true` is the command of choice here.
I would prefer fixing this upstream, but I refuse to register an account
there because GitLab.com wants me to validate an email address (sure), a
phone number (why?) and a valid payment method ([redacted]).
This fixes#273164 (»Apparmor service fails to start after nixos-rebuild
switch«).
With buildPythonApplication the PYTHONPATH is now populated properly,
which should address the ModuleNotFoundError issue.
I also moved some of the substitutions from postInstall to prePatch, so
they don't conflict with the wrapped executables.
Because upstream does not seem to hardcode binary paths in the utils
anymore, some of the old substituteInPlace rules could be removed.
Partial fix for nixpkgs#169056
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
