Comment 13 for bug 1641236

A few comments and explanations:

> As part of that it locks down /dev to read-only:
> /dev/ r,
>
> However that also means /dev/pts is read-only, hence the error above denies write access.

The rule for /dev/ only allows reading the directory listing of /dev/. It doesn't say or allow anything for /dev/pts/.

> [ 9119.221342] audit: type=1400 audit(1666766810.741:452): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 [...]
> name="apparmor/.null"

name="apparmor/.null" is a special replacement - IIRC for files or open file handles that should not be available inside the namespace. However, I'm not completely sure about this - maybe someone else can add a better explanation.

> Also is "/dev r" a faulty permission?

Not really faulty, just useless ;-)
This rule would allow to read the _file_ /dev, but since /dev is a directory, the rule doesn't give you any useful permissions.

You probably want "/dev/ r," which allows to read the directory listing (think of "ls -l /dev").

> It's notable that after I reload the apparmor profile, and sometimes randomly, the current terminal
> session has this issue go away - it seems it can resolve the path for a while. e.g. if i add and
> then remove the consoles abstraction, it suddenly works inside that session. But if I logout/login
> it breaks again.

Wild guess: are the lxd-related profiles autogenerated, and get overwritten when you logout/login or for other reasons?

Besides that, you could in theory hit a cache issue (even if it sounds unlikely in this case - changing a profile should also update its timestamp). If in doubt, check audit.log or syslog when the profile gets reloaded. You should see different messages if the profile loaded into the kernel actually changed or not.