Re: LSM stacking in next for 6.1?

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

On 2022/10/30 16:23, John Johansen wrote:
>> This reasoning is more stronger than "we don't care about out-of-tree code"
>> reasoning.
>>
> Look many developers really just don't care about out of tree code, and others
> well I won't say they don't care but its impossible task to monitor and think
> about how the broad swath of different out of tree code bits could be affected
> by kernel changes. So the only practical thing to do is make changes based on
> what is in tree and let out of tree projects deal with making the adjustments
> needed to adapt to the changing kernel.

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.