[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dbe702e7-ee63-c665-a989-255b0c1212cc@digikod.net>
Date: Tue, 12 Apr 2022 18:10:14 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Konstantin Meskhidze <konstantin.meskhidze@...wei.com>
Cc: willemdebruijn.kernel@...il.com,
linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, yusongping@...wei.com,
artem.kuzin@...wei.com, anton.sirazetdinov@...wei.com
Subject: Re: [RFC PATCH v4 07/15] landlock: user space API network support
On 12/04/2022 16:05, Konstantin Meskhidze wrote:
>
>
> 4/12/2022 4:48 PM, Mickaël Salaün пишет:
>>
>> On 12/04/2022 13:21, Mickaël Salaün wrote:
>>>
>>> On 09/03/2022 14:44, Konstantin Meskhidze wrote:
>>
>> [...]
>>
>>>> @@ -184,7 +185,7 @@ SYSCALL_DEFINE3(landlock_create_ruleset,
>>>>
>>>> /* Checks content (and 32-bits cast). */
>>>> if ((ruleset_attr.handled_access_fs | LANDLOCK_MASK_ACCESS_FS) !=
>>>> - LANDLOCK_MASK_ACCESS_FS)
>>>> + LANDLOCK_MASK_ACCESS_FS)
>>>
>>> Don't add cosmetic changes. FYI, I'm relying on the way Vim does line
>>> cuts, which is mostly tabs. Please try to do the same.
>>
>> Well, let's make it simple and avoid tacit rules. I'll update most of
>> the existing Landlock code and tests to be formatted with clang-format
>> (-i *.[ch]), and I'll update the landlock-wip branch so that you can
>> base your next patch series on it. There should be some exceptions
>> that need customization but we'll see that in the next series. Anyway,
>> don't worry too much, just make sure you don't have style-only changes
>> in your patches.
>
> I have already rebased my next patch series on your landlock-wip
> branch. So I will wait for your changes meanwhile refactoring my v5
> patch series according your comments.
Good.
>
> Also I want to discuss adding demo in sandboxer.c to show how landlock
> supports network sandboxing:
>
> - Add additional args like "LL_NET_BIND=port1:...:portN"
> - Add additional args like "LL_NET_CONNECT=port1:...:portN"
> - execv 2 bash procceses:
> 1. first bash listens in loop - $ nc -l -k -p <port1> -v
> 2. second bash to connects the first one - $ nc <ip> <port>
>
> What do you think? its possible to present this demo in the next v5
> patch series.
This looks good! I think LL_TCP_BIND and LL_TCP_CONNECT would fit better
though.
I'm not sure if I already said that, but please remove the "RFC " part
for the next series.
Powered by blists - more mailing lists