Chpasswd use occasionally causing /etc/shadow read apparmor denials

@jdstrand We are invoking chpasswd from our snap to change a password. The password change always succeeds, but occasionally we see apparmor denials like the following in the kernel dmesg log:

[75086.167553] audit: type=1400 audit(1586267299.257:39): apparmor=“DENIED” operation=“open” profile=“” name="/etc/shadow" pid=15196 comm=“chpasswd” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

Our snap has the following connections:
sudo snap connections k4connect-controller-core
Interface Plug Slot Notes
account-control k4connect-controller-core:account-control :account-control -
bluetooth-control k4connect-controller-core:bluetooth-control :bluetooth-control -
hardware-observe k4connect-controller-core:hardware-observe :hardware-observe -
mount-observe k4connect-controller-core:mount-observe :mount-observe -
network k4connect-controller-core:network :network -
network-bind k4connect-controller-core:network-bind :network-bind -
network-observe k4connect-controller-core:network-observe :network-observe -
network-setup-control k4connect-controller-core:network-setup-control :network-setup-control -
snapd-control k4connect-controller-core:snapd-control :snapd-control -
timezone-control k4connect-controller-core:timezone-control :timezone-control -

Should we be doing something differently with our snap’s connections to ensure the permissions are correct? Or is this just something we can safely ignore? We are running on a Raspberry Pi4 using a custom gadget snap that is closely based on the Pi4’s gadget snap. Thanks for any help you can provide on this.

Since the password change is succeeding, for now just ignore it. I have put this on the list for the next batch of policy updates to investigate. It sounds like a bug in chpasswd when using extrausers that it is trying to access /etc/shadow.