* [RFC PATCH] capabilities: remove cap_mmap_file()
@ 2024-09-25 19:20 Paul Moore
2024-09-25 19:45 ` Casey Schaufler
0 siblings, 1 reply; 10+ messages in thread
From: Paul Moore @ 2024-09-25 19:20 UTC (permalink / raw)
To: linux-security-module, serge
The cap_mmap_file() LSM callback returns the default value for the
security_mmap_file() LSM hook and can be safely removed.
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
security/commoncap.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index cefad323a0b1..3d103069903b 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1428,12 +1428,6 @@ int cap_mmap_addr(unsigned long addr)
return ret;
}
-int cap_mmap_file(struct file *file, unsigned long reqprot,
- unsigned long prot, unsigned long flags)
-{
- return 0;
-}
-
#ifdef CONFIG_SECURITY
static const struct lsm_id capability_lsmid = {
@@ -1453,7 +1447,6 @@ static struct security_hook_list capability_hooks[] __ro_after_init = {
LSM_HOOK_INIT(inode_killpriv, cap_inode_killpriv),
LSM_HOOK_INIT(inode_getsecurity, cap_inode_getsecurity),
LSM_HOOK_INIT(mmap_addr, cap_mmap_addr),
- LSM_HOOK_INIT(mmap_file, cap_mmap_file),
LSM_HOOK_INIT(task_fix_setuid, cap_task_fix_setuid),
LSM_HOOK_INIT(task_prctl, cap_task_prctl),
LSM_HOOK_INIT(task_setscheduler, cap_task_setscheduler),
--
2.46.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-09-25 19:20 [RFC PATCH] capabilities: remove cap_mmap_file() Paul Moore
@ 2024-09-25 19:45 ` Casey Schaufler
2024-09-26 13:11 ` Serge E. Hallyn
0 siblings, 1 reply; 10+ messages in thread
From: Casey Schaufler @ 2024-09-25 19:45 UTC (permalink / raw)
To: Paul Moore, linux-security-module, serge
On 9/25/2024 12:20 PM, Paul Moore wrote:
> The cap_mmap_file() LSM callback returns the default value for the
> security_mmap_file() LSM hook and can be safely removed.
>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> security/commoncap.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index cefad323a0b1..3d103069903b 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -1428,12 +1428,6 @@ int cap_mmap_addr(unsigned long addr)
> return ret;
> }
>
> -int cap_mmap_file(struct file *file, unsigned long reqprot,
> - unsigned long prot, unsigned long flags)
> -{
> - return 0;
> -}
> -
> #ifdef CONFIG_SECURITY
>
> static const struct lsm_id capability_lsmid = {
> @@ -1453,7 +1447,6 @@ static struct security_hook_list capability_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(inode_killpriv, cap_inode_killpriv),
> LSM_HOOK_INIT(inode_getsecurity, cap_inode_getsecurity),
> LSM_HOOK_INIT(mmap_addr, cap_mmap_addr),
> - LSM_HOOK_INIT(mmap_file, cap_mmap_file),
> LSM_HOOK_INIT(task_fix_setuid, cap_task_fix_setuid),
> LSM_HOOK_INIT(task_prctl, cap_task_prctl),
> LSM_HOOK_INIT(task_setscheduler, cap_task_setscheduler),
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-09-25 19:45 ` Casey Schaufler
@ 2024-09-26 13:11 ` Serge E. Hallyn
2024-09-26 13:16 ` Paul Moore
0 siblings, 1 reply; 10+ messages in thread
From: Serge E. Hallyn @ 2024-09-26 13:11 UTC (permalink / raw)
To: Casey Schaufler; +Cc: Paul Moore, linux-security-module, serge
On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> On 9/25/2024 12:20 PM, Paul Moore wrote:
> > The cap_mmap_file() LSM callback returns the default value for the
> > security_mmap_file() LSM hook and can be safely removed.
> >
> > Signed-off-by: Paul Moore <paul@paul-moore.com>
>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
>
> > ---
> > security/commoncap.c | 7 -------
> > 1 file changed, 7 deletions(-)
> >
> > diff --git a/security/commoncap.c b/security/commoncap.c
> > index cefad323a0b1..3d103069903b 100644
> > --- a/security/commoncap.c
> > +++ b/security/commoncap.c
> > @@ -1428,12 +1428,6 @@ int cap_mmap_addr(unsigned long addr)
> > return ret;
> > }
> >
> > -int cap_mmap_file(struct file *file, unsigned long reqprot,
> > - unsigned long prot, unsigned long flags)
> > -{
> > - return 0;
> > -}
> > -
> > #ifdef CONFIG_SECURITY
> >
> > static const struct lsm_id capability_lsmid = {
> > @@ -1453,7 +1447,6 @@ static struct security_hook_list capability_hooks[] __ro_after_init = {
> > LSM_HOOK_INIT(inode_killpriv, cap_inode_killpriv),
> > LSM_HOOK_INIT(inode_getsecurity, cap_inode_getsecurity),
> > LSM_HOOK_INIT(mmap_addr, cap_mmap_addr),
> > - LSM_HOOK_INIT(mmap_file, cap_mmap_file),
> > LSM_HOOK_INIT(task_fix_setuid, cap_task_fix_setuid),
> > LSM_HOOK_INIT(task_prctl, cap_task_prctl),
> > LSM_HOOK_INIT(task_setscheduler, cap_task_setscheduler),
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-09-26 13:11 ` Serge E. Hallyn
@ 2024-09-26 13:16 ` Paul Moore
2024-09-26 13:22 ` Serge E. Hallyn
0 siblings, 1 reply; 10+ messages in thread
From: Paul Moore @ 2024-09-26 13:16 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Casey Schaufler, linux-security-module
On Thu, Sep 26, 2024 at 9:11 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> > On 9/25/2024 12:20 PM, Paul Moore wrote:
> > > The cap_mmap_file() LSM callback returns the default value for the
> > > security_mmap_file() LSM hook and can be safely removed.
> > >
> > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> >
> > Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
Thanks Serge. Any interest in pulling this via the capabilities tree
or would you prefer I take this via the LSM tree?
--
paul-moore.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-09-26 13:16 ` Paul Moore
@ 2024-09-26 13:22 ` Serge E. Hallyn
2024-09-26 13:24 ` Paul Moore
0 siblings, 1 reply; 10+ messages in thread
From: Serge E. Hallyn @ 2024-09-26 13:22 UTC (permalink / raw)
To: Paul Moore; +Cc: Serge E. Hallyn, Casey Schaufler, linux-security-module
On Thu, Sep 26, 2024 at 09:16:04AM -0400, Paul Moore wrote:
> On Thu, Sep 26, 2024 at 9:11 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> > > On 9/25/2024 12:20 PM, Paul Moore wrote:
> > > > The cap_mmap_file() LSM callback returns the default value for the
> > > > security_mmap_file() LSM hook and can be safely removed.
> > > >
> > > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > >
> > > Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> >
> > Reviewed-by: Serge Hallyn <serge@hallyn.com>
>
> Thanks Serge. Any interest in pulling this via the capabilities tree
> or would you prefer I take this via the LSM tree?
Oh, jinkeys - I guess should take it through the capabilities tree if
only to check that it still works!
thanks,
-serge
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-09-26 13:22 ` Serge E. Hallyn
@ 2024-09-26 13:24 ` Paul Moore
2024-09-30 21:08 ` Serge E. Hallyn
0 siblings, 1 reply; 10+ messages in thread
From: Paul Moore @ 2024-09-26 13:24 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Casey Schaufler, linux-security-module
On Thu, Sep 26, 2024 at 9:22 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> On Thu, Sep 26, 2024 at 09:16:04AM -0400, Paul Moore wrote:
> > On Thu, Sep 26, 2024 at 9:11 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> > > > On 9/25/2024 12:20 PM, Paul Moore wrote:
> > > > > The cap_mmap_file() LSM callback returns the default value for the
> > > > > security_mmap_file() LSM hook and can be safely removed.
> > > > >
> > > > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > > >
> > > > Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> > >
> > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> >
> > Thanks Serge. Any interest in pulling this via the capabilities tree
> > or would you prefer I take this via the LSM tree?
>
> Oh, jinkeys - I guess should take it through the capabilities tree if
> only to check that it still works!
:)
Sounds good, if you change your mind let me know and I'll pick this up.
--
paul-moore.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-09-26 13:24 ` Paul Moore
@ 2024-09-30 21:08 ` Serge E. Hallyn
2024-10-01 14:08 ` Paul Moore
0 siblings, 1 reply; 10+ messages in thread
From: Serge E. Hallyn @ 2024-09-30 21:08 UTC (permalink / raw)
To: Paul Moore; +Cc: Serge E. Hallyn, Casey Schaufler, linux-security-module
On Thu, Sep 26, 2024 at 09:24:06AM -0400, Paul Moore wrote:
> On Thu, Sep 26, 2024 at 9:22 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Sep 26, 2024 at 09:16:04AM -0400, Paul Moore wrote:
> > > On Thu, Sep 26, 2024 at 9:11 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > > On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> > > > > On 9/25/2024 12:20 PM, Paul Moore wrote:
> > > > > > The cap_mmap_file() LSM callback returns the default value for the
> > > > > > security_mmap_file() LSM hook and can be safely removed.
> > > > > >
> > > > > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > > > >
> > > > > Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> > > >
> > > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> > >
> > > Thanks Serge. Any interest in pulling this via the capabilities tree
> > > or would you prefer I take this via the LSM tree?
> >
> > Oh, jinkeys - I guess should take it through the capabilities tree if
> > only to check that it still works!
>
> :)
>
> Sounds good, if you change your mind let me know and I'll pick this up.
Just got access back to my kernel.org account. Too late for 6.12 cycle, so
I'll keep it ready for 6.13 window. I suppose I should see about hooking
back into the -next kernel for testing.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-09-30 21:08 ` Serge E. Hallyn
@ 2024-10-01 14:08 ` Paul Moore
2024-10-01 21:20 ` Serge E. Hallyn
0 siblings, 1 reply; 10+ messages in thread
From: Paul Moore @ 2024-10-01 14:08 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Casey Schaufler, linux-security-module
On Mon, Sep 30, 2024 at 5:08 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> On Thu, Sep 26, 2024 at 09:24:06AM -0400, Paul Moore wrote:
> > On Thu, Sep 26, 2024 at 9:22 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > On Thu, Sep 26, 2024 at 09:16:04AM -0400, Paul Moore wrote:
> > > > On Thu, Sep 26, 2024 at 9:11 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > > > On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> > > > > > On 9/25/2024 12:20 PM, Paul Moore wrote:
> > > > > > > The cap_mmap_file() LSM callback returns the default value for the
> > > > > > > security_mmap_file() LSM hook and can be safely removed.
> > > > > > >
> > > > > > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > > > > >
> > > > > > Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> > > > >
> > > > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> > > >
> > > > Thanks Serge. Any interest in pulling this via the capabilities tree
> > > > or would you prefer I take this via the LSM tree?
> > >
> > > Oh, jinkeys - I guess should take it through the capabilities tree if
> > > only to check that it still works!
> >
> > :)
> >
> > Sounds good, if you change your mind let me know and I'll pick this up.
>
> Just got access back to my kernel.org account. Too late for 6.12 cycle, so
> I'll keep it ready for 6.13 window. I suppose I should see about hooking
> back into the -next kernel for testing.
Sorry for the delay, network access was spotty over the past few days,
and what little I did have was just my phone.
Anyway, yes, this was intended for v6.13 anyway so no harm there.
Glad you're setup again on kernel.org.
Hooking up to linux-next is pretty easy, basically just send some
mail, but if I can offer a suggestion you might want to make your
linux-next branch a automatically generated "composite" branch so you
are better able to get both linux-stable and linux-next patches tested
via the normal linux-next mechanisms. I'm sure you've seen this
already, but here is the approach I take with the LSM tree:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git/tree/README.md#n94
--
paul-moore.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-10-01 14:08 ` Paul Moore
@ 2024-10-01 21:20 ` Serge E. Hallyn
2024-10-02 15:36 ` Paul Moore
0 siblings, 1 reply; 10+ messages in thread
From: Serge E. Hallyn @ 2024-10-01 21:20 UTC (permalink / raw)
To: Paul Moore; +Cc: Serge E. Hallyn, Casey Schaufler, linux-security-module
On Tue, Oct 01, 2024 at 10:08:04AM -0400, Paul Moore wrote:
> On Mon, Sep 30, 2024 at 5:08 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Sep 26, 2024 at 09:24:06AM -0400, Paul Moore wrote:
> > > On Thu, Sep 26, 2024 at 9:22 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > > On Thu, Sep 26, 2024 at 09:16:04AM -0400, Paul Moore wrote:
> > > > > On Thu, Sep 26, 2024 at 9:11 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > > > > On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> > > > > > > On 9/25/2024 12:20 PM, Paul Moore wrote:
> > > > > > > > The cap_mmap_file() LSM callback returns the default value for the
> > > > > > > > security_mmap_file() LSM hook and can be safely removed.
> > > > > > > >
> > > > > > > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > > > > > >
> > > > > > > Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> > > > > >
> > > > > > Reviewed-by: Serge Hallyn <serge@hallyn.com>
> > > > >
> > > > > Thanks Serge. Any interest in pulling this via the capabilities tree
> > > > > or would you prefer I take this via the LSM tree?
> > > >
> > > > Oh, jinkeys - I guess should take it through the capabilities tree if
> > > > only to check that it still works!
> > >
> > > :)
> > >
> > > Sounds good, if you change your mind let me know and I'll pick this up.
> >
> > Just got access back to my kernel.org account. Too late for 6.12 cycle, so
> > I'll keep it ready for 6.13 window. I suppose I should see about hooking
> > back into the -next kernel for testing.
>
> Sorry for the delay, network access was spotty over the past few days,
> and what little I did have was just my phone.
>
> Anyway, yes, this was intended for v6.13 anyway so no harm there.
> Glad you're setup again on kernel.org.
>
> Hooking up to linux-next is pretty easy, basically just send some
> mail, but if I can offer a suggestion you might want to make your
> linux-next branch a automatically generated "composite" branch so you
> are better able to get both linux-stable and linux-next patches tested
> via the normal linux-next mechanisms. I'm sure you've seen this
> already, but here is the approach I take with the LSM tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git/tree/README.md#n94
Thanks! I thought in the past there had been "how to best work with
linux-next" guides out there, but I spent some time looking through
linux.git/Documentation, linux-next/, lore.kernel.org, and kernelnewbies
and google and came up with nothing.
-serge
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC PATCH] capabilities: remove cap_mmap_file()
2024-10-01 21:20 ` Serge E. Hallyn
@ 2024-10-02 15:36 ` Paul Moore
0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2024-10-02 15:36 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Casey Schaufler, linux-security-module
On Tue, Oct 1, 2024 at 5:20 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> On Tue, Oct 01, 2024 at 10:08:04AM -0400, Paul Moore wrote:
> > On Mon, Sep 30, 2024 at 5:08 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > On Thu, Sep 26, 2024 at 09:24:06AM -0400, Paul Moore wrote:
> > > > On Thu, Sep 26, 2024 at 9:22 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > > > On Thu, Sep 26, 2024 at 09:16:04AM -0400, Paul Moore wrote:
> > > > > > On Thu, Sep 26, 2024 at 9:11 AM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > > > > > On Wed, Sep 25, 2024 at 12:45:20PM -0700, Casey Schaufler wrote:
> > > > > > > > On 9/25/2024 12:20 PM, Paul Moore wrote:
...
> > > Just got access back to my kernel.org account. Too late for 6.12 cycle, so
> > > I'll keep it ready for 6.13 window. I suppose I should see about hooking
> > > back into the -next kernel for testing.
> >
> > Sorry for the delay, network access was spotty over the past few days,
> > and what little I did have was just my phone.
> >
> > Anyway, yes, this was intended for v6.13 anyway so no harm there.
> > Glad you're setup again on kernel.org.
> >
> > Hooking up to linux-next is pretty easy, basically just send some
> > mail, but if I can offer a suggestion you might want to make your
> > linux-next branch a automatically generated "composite" branch so you
> > are better able to get both linux-stable and linux-next patches tested
> > via the normal linux-next mechanisms. I'm sure you've seen this
> > already, but here is the approach I take with the LSM tree:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git/tree/README.md#n94
>
> Thanks! I thought in the past there had been "how to best work with
> linux-next" guides out there, but I spent some time looking through
> linux.git/Documentation, linux-next/, lore.kernel.org, and kernelnewbies
> and google and came up with nothing.
Full disclosure, the guidance above is based simply on WORKSFORME
based on experience and discussions with the linux-next folks, please
don't take it as any official guide, I post it only so that people who
are contributing know what to expect.
--
paul-moore.com
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-10-02 15:36 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-25 19:20 [RFC PATCH] capabilities: remove cap_mmap_file() Paul Moore
2024-09-25 19:45 ` Casey Schaufler
2024-09-26 13:11 ` Serge E. Hallyn
2024-09-26 13:16 ` Paul Moore
2024-09-26 13:22 ` Serge E. Hallyn
2024-09-26 13:24 ` Paul Moore
2024-09-30 21:08 ` Serge E. Hallyn
2024-10-01 14:08 ` Paul Moore
2024-10-01 21:20 ` Serge E. Hallyn
2024-10-02 15:36 ` Paul Moore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).