[RFC PATCH 00/29] acl: add vfs posix acl api

[Casey Schaufler]

On 9/23/2022 1:52 AM, Christian Brauner wrote:
> On Thu, Sep 22, 2022 at 06:13:44PM -0400, Paul Moore wrote:
>> On Thu, Sep 22, 2022 at 5:57 PM Serge E. Hallyn <serge at hallyn.com> wrote:
>>> On Thu, Sep 22, 2022 at 03:07:44PM -0400, Paul Moore wrote:
>>>> On Thu, Sep 22, 2022 at 2:54 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>>> On 9/22/2022 10:57 AM, Linus Torvalds wrote:
>>>>>> On Thu, Sep 22, 2022 at 9:27 AM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>>>>> Could we please see the entire patch set on the LSM list?
>>>>>> While I don't think that's necessarily wrong, I would like to point
>>>>>> out that the gitweb interface actually does make it fairly easy to
>>>>>> just see the whole patch-set.
>>>>>>
>>>>>> IOW, that
>>>>>>
>>>>>>   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git/log/?h=fs.acl.rework
>>>>>>
>>>>>> that Christian pointed to is not a horrible way to see it all. Go to
>>>>>> the top-most commit, and it's easy to follow the parent links.
>>>>> I understand that the web interface is fine for browsing the changes.
>>>>> It isn't helpful for making comments on the changes. The discussion
>>>>> on specific patches (e.g. selinux) may have impact on other parts of
>>>>> the system (e.g. integrity) or be relevant elsewhere (e.g. smack). It
>>>>> can be a real problem if the higher level mailing list (the LSM list
>>>>> in this case) isn't included.
>>>> This is probably one of those few cases where Casey and I are in
>>>> perfect agreement.  I'd much rather see the patches hit my inbox than
>>>> have to go hunting for them and then awkwardly replying to them (and
>>>> yes, I know there are ways to do that, I just personally find it
>>>> annoying).  I figure we are all deluged with email on a daily basis
>>>> and have developed mechanisms to deal with that in a sane way, what is
>>>> 29 more patches on the pile?
>>> Even better than the web interface, is find the message-id in any of the
>>> emails you did get, and run
>>>
>>> b4 mbox 20220922151728.1557914-1-brauner at kernel.org
>>>
>>> In general I'd agree with sending the whole set to the lsm list, but
>>> then one needs to start knowing which lists do and don't want the whole
>>> set...  b4 mbox and lei are now how I read all kernel related lists.

Because of commonalities and interactions among the various security modules,
along with the ongoing efforts to enhance the infrastructure and the close
ties with the vfs and audit system, it's rare that the LSM crowd isn't going
to want to see the whole of a change.

>> In my opinion, sending the entire patchset to the relevant lists
>> should be the default for all the reasons mentioned above.  All the
>> other methods are fine, and I don't want to stop anyone from using
>> their favorite tool, but *requiring* the use of a separate tool to
>> properly review and comment on patches gets us away from the
>> email-is-universal argument.  Yes, all the other tools mentioned are
>> still based in a world of email, but if you are not emailing the
>> relevant stakeholders directly (or indirectly via a list), you are
>> placing another hurdle in front of the reviewers by requiring them to
>> leave their email client based workflow and jump over to lore, b4,
>> etc. to review the patchset.
>>
>> The lore.kernel.org instance is wonderful, full stop, and the b4 tool
>> is equally wonderful, full stop, but they are tools intended to assist
>> and optimize; they should not replace the practice of sending patches,
>> with the full context, to the relevant parties.
> I'm happy to send all of v2 to the security mailing list.

Thank you.

> But for v1 could you compromise and just use b4?

I cringe whenever someone says "just".

I'm sure b4 is a fine tool. I'm told mutt is useful. Gitweb is kewl.
But adopting a new and exciting development methodology every few
years since about 1978 has given me a real appreciation for the
raw email approach. I'll wait for v2.

>
> b4 mbox 20220922151728.1557914-1-brauner at kernel.org
>
> This would mean you could provide reviews for v1 and we don't need to
> fragment the v1 discussion because of a resend to include a mailing list.

Right, but I would need to learn yet another development tool set.
I fully expect you'd have v2 ready before I could be sufficiently
proficient with b4+mutt to contribute.