diff mbox series

[RFC] capabilities: remove cap_mmap_file()

Message ID 20240925192018.15290-2-paul@paul-moore.com (mailing list archive)
State Handled Elsewhere
Delegated to: Paul Moore
Headers show
Series [RFC] capabilities: remove cap_mmap_file() | expand

Commit Message

Paul Moore Sept. 25, 2024, 7:20 p.m. UTC
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(-)

Comments

Casey Schaufler Sept. 25, 2024, 7:45 p.m. UTC | #1
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),
Serge E. Hallyn Sept. 26, 2024, 1:11 p.m. UTC | #2
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),
Paul Moore Sept. 26, 2024, 1:16 p.m. UTC | #3
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?
Serge E. Hallyn Sept. 26, 2024, 1:22 p.m. UTC | #4
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
Paul Moore Sept. 26, 2024, 1:24 p.m. UTC | #5
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.
Serge E. Hallyn Sept. 30, 2024, 9:08 p.m. UTC | #6
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.
Paul Moore Oct. 1, 2024, 2:08 p.m. UTC | #7
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
Serge E. Hallyn Oct. 1, 2024, 9:20 p.m. UTC | #8
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
Paul Moore Oct. 2, 2024, 3:36 p.m. UTC | #9
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.
diff mbox series

Patch

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),