On 8/6/19 7:36 PM, Mikhail Morfikov wrote: > On 07/08/2019 00:24, Seth Arnold wrote: >> - run both processes in the same filesystem namespace, so files have names >> that are meaningful to both >> > > I though they both run in the same filesystem namespace. > It's just /usr/sbin/deluser which executes /usr/sbin/userdel . > > Here are the two profiles: > https://pastebin.com/raw/8cDyVh8J > https://pastebin.com/raw/Etxm2h88 > >
info="Failed name lookup - disconnected path" tends to happen when the applications are in different mount namespaces, and an fd is passed between them, either through inheritance or explicitly over a socket. It does not guarantee that it is due to the tasks being in a separate mount namespace. Looking further we see name="apparmor/.null" says that it is an fd that was inherited and apparmor did a revalidation on it and the access was denied so the fd was duped to a special null device files instead of out right closing it (there are good reasons for doing this). So you will need to look back in your log for an apparmor=DENIED message, with operation="file_inherit" that should give you the actual file in this case. I should note that on newer kernels we don't generally audit apparmor/.null so you will only get the file_inherit denial logged.
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
