[PATCH 04/10] CaitSith: Add header file.

[Tetsuo Handa]

On 2022/11/09 11:20, Paul Moore wrote:
> On Tue, Nov 8, 2022 at 5:20 AM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>> What I'm asking you are that:
>>
>>   Please don't lock out out-of-tree LSM modules (by requiring an LSM id integer value
>>   which are assigned to only in-tree LSM modules) because we can't accept whatever LSM
>>   modules as in-tree.
>>
>>   Please don't lock out loadable LSM modules (by using fixed sized array) because
>>   locking out loadable LSM modules reduces the value of your LSM stacking work.
>>
>> Quite simple.
> 
> Tetsuo, at this point I think we all understand your concern and I
> appreciate and respect the passion you have for your argument.
> However, I think the rest of the developers, including myself, have
> also made our points very clear.  While there may still be revisions
> to the syscall patches, I believe identifying LSMs via a token value
> as opposed to a string value is the better option for the upstream
> Linux Kernel.

I'm not opposing to identifying LSMs via a token value. I'm opposing to who can
obtain a token value, for I haven't heard a clear promise that we shall allow
whatever LSM modules to obtain a token value.

>                This alone should not prevent dynamically loadable LSMs
> in the future, if we decide to pursue that, but I do recognize that it
> will present more of a challenge for the long term maintenance of
> out-of-tree LSMs.

Who can obtain a token value affects both built-in LSM modules and dynamically
loadable LSM modules. A "code that is being developed in the open with the
*intention* to be submitted to be in-tree" has to be able to obtain a token
value as soon as starting development (which is much earlier stage than getting
that code in-tree).

Do you remember that you said

  >> Currently anyone can start writing new LSM modules using name as identifier. But
  >> you are trying to forbid using name as identifier, and trying to force using integer
  >> as identifier, but that integer will not be provided unless new LSM modules get
  >> upstream.
  > 
  > That is correct.  In order to have a LSM identifier token the LSM must
  > be upstream.

at https://lkml.kernel.org/r/CAHC9VhT2Azg1F-G3RQ4xL7JgA3OAtHafzS1_nvUyEUFsCJ9+SA@mail.gmail.com ?

If in-tree kernel refuses to assign a token value, no new LSM module would be developed
in the open, for not-yet-in-tree code (in whatever stage) cannot use a token value for
registering into the LSM framework.

>                    I see no reason to trade off what I believe as a
> better API choice (LSM ID tokens) for something that is explicitly not
> supported by the Linux Kernel as a whole (out-of-tree kernel code).

And even if a "code is being developed in the open with the intention to be
submitted to be in-tree, and actually submitted for in-tree", we know that we
cannot accept all submitted LSM modules. LSM modules which were not accepted for
in-tree have to remain out-of-tree.

We don't make patches for out-of-tree code in order to catch up to upstream kernel
changes. But we didn't and must not try to forbid out-of-tree code to exist.

Although I'm not a fan of proprietary / closed source code, I have to resist
Casey's attempt to lock out out-of-tree code and new code.

> 
> Thank you for your comments, but I'm considering this settled.
> 

Never settled, unless you all promise that we shall assign a token value to whatever
LSM modules (regardless of whether that LSM module is already in-tree or not).