Re: LSM stacking in next for 6.1?

On 2022/10/30 16:23, John Johansen wrote: I don't care that out of tree projects have to deal with the burden of making the adjustments needed to adapt to the changing kernel. But I do care that out of tree projects are allowed to make the adjustments needed to adapt to the changing kernel. Think about the PCI ID Repository ( https://pci-ids.ucw.cz ) as an example. A PCI ID value can be assigned to a hardware device, regardless of whether a device driver for Linux kernel is available in the upstream kernel. 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.