nixpkgs/pkgs/os-specific/linux/apparmor
Andreas Wiese b69ffeb3a2 apparmor-utils: fix aa-remove-unknown read check
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«).
2024-02-05 09:50:58 +01:00
..
0001-aa-remove-unknown_empty-ruleset.patch apparmor-utils: fix aa-remove-unknown read check 2024-02-05 09:50:58 +01:00
default.nix apparmor-utils: fix aa-remove-unknown read check 2024-02-05 09:50:58 +01:00
fix-rc.apparmor.functions.sh Revert "Revert "apparmor: fix and improve the service"" 2021-04-23 07:17:55 +02:00