Re: LSM stacking in next for 6.1?

Casey's patchset is trying to provide LSM ID Repository for userspace programs. But an LSM ID value cannot be assigned to that LSM unless that module is available in the upstream kernel. This means that, developers are not allowed to develop a new LSM module even with the intention to become available in the upstream kernel, for there always is a risk of LSM ID collision which the LSM ID Repository should have avoided from the beginning. Also, this means that, unlike PCI devices, users are not allowed to use out-of-tree LSM modules which have to remain out-of-tree due to proposed-but-not-accepted by the upstream kernel. This is a serious bug; is LSM a proprietary/closed code where modification is impossible due to an End-User License Agreement?

You have only three choices: (1) allow assigning LSM ID integer value to all LSM modules (regardless of whether that module was merged into upstream kernel)

(2) use module name string value as LSM ID

(3) dynamically assign LSM ID integer value when an LSM module is registered

There never is fourth choice: (4) assigning LSM ID integer value to only LSM modules which were merged into upstream kernel The fourth choice is complete lockout of out of tree projects.