[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <07a496b2-ed1f-4a18-88d1-7be36dba3a8a@canonical.com>
Date: Thu, 8 May 2025 07:44:35 -0700
From: John Johansen <john.johansen@...onical.com>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
Maxime Bélair <maxime.belair@...onical.com>,
linux-security-module@...r.kernel.org
Cc: paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
mic@...ikod.net, kees@...nel.org, stephen.smalley.work@...il.com,
casey@...aufler-ca.com, takedakn@...data.co.jp, linux-api@...r.kernel.org,
apparmor@...ts.ubuntu.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
On 5/8/25 05:55, Tetsuo Handa wrote:
> On 2025/05/08 17:25, John Johansen wrote:
>> That is fine. But curious I am curious what the interface would look like to fit TOMOYO's
>> needs.
>
> Stream (like "FILE *") with restart from the beginning (like rewind(fp)) support.
> That is, the caller can read/write at least one byte at a time, and written data
> is processed upon encountering '\n'.
>
that can be emulated within the current sycall, where the lsm maintains a buffer.
Are you asking to also read data back out as well, that could be added, but doing
a syscall per byte here or through the fs is going to have fairly high overhead.
Without understanding the requirement it would seem to me, that it would be
better to emulate that file buffer manipulation in userspace similar say C++
stringstreams, and then write the syscall when done.
Powered by blists - more mailing lists