xfrm: Can "struct netlbl_audit" be killed?

xfrm: Can "struct netlbl_audit" be killed?

[Tetsuo Handa]

Hello, Casey and Paul.

At the ipsec-next tree,

  /* Audit Information */
  struct xfrm_audit {
  	u32     secid;
  	kuid_t  loginuid;
  	unsigned int sessionid;
  };

has just been killed
( https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/commit/?id=f1370cc4a01e61007ab3020c761cef6b88ae3729 and
  https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/commit/?id=2e71029e2c32ecd59a2e8f351517bfbbad42ac11 )
because these arguments are always calculated from current thread's security
context.

Looking at other security_secid_to_secctx() users, I noticed that
a similar struct in the netlabel code.

  /* NetLabel audit information */
  struct netlbl_audit {
  	u32 secid;
  	kuid_t loginuid;
  	unsigned int sessionid;
  };

Do you know whether we can kill "struct netlbl_audit" as well?
(In other words, is "bool" sufficient for representing "struct netlbl_audit" ?)

Regards.

Re: xfrm: Can "struct netlbl_audit" be killed?

[Paul Moore]

On Thursday, April 24, 2014 08:51:35 PM Tetsuo Handa wrote:
> Hello, Casey and Paul.
> 
> At the ipsec-next tree,
> 
>   /* Audit Information */
>   struct xfrm_audit {
>   	u32     secid;
>   	kuid_t  loginuid;
>   	unsigned int sessionid;
>   };
> 
> has just been killed
> (
> https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/commit
> /?id=f1370cc4a01e61007ab3020c761cef6b88ae3729 and
> https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/commit
> /?id=2e71029e2c32ecd59a2e8f351517bfbbad42ac11 ) because these arguments are
> always calculated from current thread's security context.

Before we go to far, is it always true for AF_KEY that "current" is set to the 
sending process?  If the answer is no, I think we have a problem.

-- 
paul moore
www.paul-moore.com

Re: xfrm: Can "struct netlbl_audit" be killed?

[Tetsuo Handa]

Paul Moore wrote:
> On Thursday, April 24, 2014 08:51:35 PM Tetsuo Handa wrote:
> > Hello, Casey and Paul.
> > 
> > At the ipsec-next tree,
> > 
> >   /* Audit Information */
> >   struct xfrm_audit {
> >   	u32     secid;
> >   	kuid_t  loginuid;
> >   	unsigned int sessionid;
> >   };
> > 
> > has just been killed
> > (
> > https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/commit
> > /?id=f1370cc4a01e61007ab3020c761cef6b88ae3729 and
> > https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/commit
> > /?id=2e71029e2c32ecd59a2e8f351517bfbbad42ac11 ) because these arguments are
> > always calculated from current thread's security context.
> 
> Before we go to far, is it always true for AF_KEY that "current" is set to the 
> sending process?  If the answer is no, I think we have a problem.

Speak of "struct xfrm_audit", I think the answer is yes, or commit ab5f5e8b
"[XFRM]: xfrm audit calls" is wrong.

Re: xfrm: Can "struct netlbl_audit" be killed?

[Paul Moore]

On Thursday, April 24, 2014 11:29:08 PM Tetsuo Handa wrote:
> Paul Moore wrote:
> > On Thursday, April 24, 2014 08:51:35 PM Tetsuo Handa wrote:
> > > Hello, Casey and Paul.
> > > 
> > > At the ipsec-next tree,
> > > 
> > >   /* Audit Information */
> > >   struct xfrm_audit {
> > >   
> > >   	u32     secid;
> > >   	kuid_t  loginuid;
> > >   	unsigned int sessionid;
> > >   
> > >   };
> > > 
> > > has just been killed
> > > (
> > > https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/com
> > > mit
> > > /?id=f1370cc4a01e61007ab3020c761cef6b88ae3729 and
> > > https://git.kernel.org/cgit/linux/kernel/git/klassert/ipsec-next.git/com
> > > mit
> > > /?id=2e71029e2c32ecd59a2e8f351517bfbbad42ac11 ) because these arguments
> > > are
> > > always calculated from current thread's security context.
> > 
> > Before we go to far, is it always true for AF_KEY that "current" is set to
> > the sending process?  If the answer is no, I think we have a problem.
> 
> Speak of "struct xfrm_audit", I think the answer is yes, or commit ab5f5e8b
> "[XFRM]: xfrm audit calls" is wrong.

I'm not assuming that ab5f5e8b is correct.  It would be nice to know for sure 
that current is always equal to the sending process for AF_KEY, and that isn't 
something I'm certain is true off the top of my head.

-- 
paul moore
www.paul-moore.com