To: casey@schaufler-ca.com, linux-security-module@vger.kernel.org,
        jmorris@namei.org
Cc: john.johansen@canonical.com, paul@paul-moore.com,
        keescook@chromium.org, sds@tycho.nsa.gov, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/3] LSM: Add /sys/kernel/security/lsm
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
References: <00f80c77-9623-7e9e-8980-63b362a4f16c@schaufler-ca.com>
        <511ae6ef-9dc1-6e43-4a49-4055727dc099@schaufler-ca.com>
        <201611012153.IHJ52634.OSOLMFFOFVQJtH@I-love.SAKURA.ne.jp>
        <9d703b12-7b17-38a9-50c8-4bcaba8ce08f@schaufler-ca.com>
In-Reply-To: <9d703b12-7b17-38a9-50c8-4bcaba8ce08f@schaufler-ca.com>
Message-Id: <201611042311.IHI81705.FSOQVMtFJLOFHO@I-love.SAKURA.ne.jp>
Date: Fri, 4 Nov 2016 23:11:54 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 872
Lines: 22

Casey Schaufler wrote:
> On 11/1/2016 5:53 AM, Tetsuo Handa wrote:
> > I didn't check past discussion, but how do you handle security_delete_hooks()
> > case (I mean, "selinux" will remain there when reading /sys/kernel/security/lsm
> > even after it is disabled at runtime)?
> 
> Paul Moore says that SELinux is going to remove the ability
> to delete itself in the near future. Since that's the only
> module that allows deletion I don't see that it's an issue.

OK.

> 
> > I think holding module name as one of
> > "union security_list_options" members will avoid memory allocation handling
> > and simplify things.
> 
> I don't see how that would simplify things, and the memory
> allocation handling here is pretty basic.

I expected we can use simple_read_from_buffer() from iteration loop,
but I found it does not work like I want. So, it did not simplify things.