A. For a custom admin, assigning a deny permission to a fixed node/path requires read/get permission to that node. So far so good.

B. Now, since MGNLUI-3838:

We now validate sub-node permissions in a more fine-grained way: in particular, in order to grant a sub-node permission (say RW on /foo sub-nodes), admin must not have any permission to a sub-path of that node, with lower permission (RO on /foo/bar). This way, we now also ensure admins cannot lift their own restrictions by assigning higher-level recursive permissions to another user/role in their control.

If I get this straight, A. and B. combined mean that the validator converts deny requirement to read, then current user's deny permissions get considered as violations, being lower than read.

Given a custom admin role with Deny access to /foo/bar (right-side of the screenshot),
a custom admin user cannot deny permission to /foo (left-side of the screenshot).
I believe he could, as this cannot lead to lifting one's restrictions.

Again, this one is also mitigated when superusers manage roles (they can grant anything practically), but needs to be fixed for multi-tenancy scenarios.