Paul Moore [off-list ref] writes:

On Wed, Aug 17, 2022 at 3:58 PM Eric W. Biederman [off-list ref] wrote:

quoted

Paul Moore [off-list ref] writes:

quoted

At the end of the v4 patchset I suggested merging this into lsm/next
so it could get a full -rc cycle in linux-next, assuming no issues
were uncovered during testing

What in the world can be uncovered in linux-next for code that has no in
tree users.

The patchset provides both BPF LSM and SELinux implementations of the
hooks along with a BPF LSM test under tools/testing/selftests/bpf/.
If no one beats me to it, I plan to work on adding a test to the
selinux-testsuite as soon as I'm done dealing with other urgent
LSM/SELinux issues (io_uring CMD passthrough, SCTP problems, etc.); I
run these tests multiple times a week (multiple times a day sometimes)
against the -rcX kernels with the lsm/next, selinux/next, and
audit/next branches applied on top.  I know others do similar things.

A layer of hooks that leaves all of the logic to userspace is not an
in-tree user for purposes of understanding the logic of the code.


The reason why I implemented user namespaces is so that all of linux's
neat features could be exposed to non-root userspace processes, in
a way that doesn't break suid root processes.


The access control you are adding to user namespaces looks to take that
away.  It looks to remove the whole point of user namespaces.


So without any mention of how people intend to use this feature, without
any code that uses this hook to implement semantics.  Without any talk
about how this semantic change is reasonable.  I strenuously object.

Eric