Re: [PATCH 04/12] selinux: Allocate and free infiniband security hooks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/1/2016 3:13 PM, Casey Schaufler wrote:
> On 7/1/2016 12:17 PM, Paul Moore wrote:
>> On Fri, Jul 1, 2016 at 2:59 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
>>> On 7/1/2016 1:54 PM, Paul Moore wrote:
>>>> On Thu, Jun 30, 2016 at 5:48 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
>>>>> On 6/30/2016 4:06 PM, Casey Schaufler wrote:
>>>>>> On 6/30/2016 1:42 PM, Paul Moore wrote:
>>>>>>>>  };
>>>>>>>>
>>>>>>>>  /**
>>>>>>>> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
>>>>>>>> index 3f6780b..e522acb 100644
>>>>>>>> --- a/include/rdma/ib_verbs.h
>>>>>>>> +++ b/include/rdma/ib_verbs.h
>>>>>>>> @@ -1454,6 +1454,7 @@ struct ib_qp {
>>>>>>>>         void                   *qp_context;
>>>>>>>>         u32                     qp_num;
>>>>>>>>         enum ib_qp_type         qp_type;
>>>>>>>> +       struct ib_qp_security  *qp_sec;
>>>>>>> See my earlier question/comment about just using a void pointer here.
>>>>>> I think that this is in response to my comments to the
>>>>>> effect that I would like to see the LSM infrastructure
>>>>>> using the inode like (inode->i_security) to the xfrm
>>>>>> (void *) approach. I haven't been looking at the IB patches
>>>>>> too carefully to date. It's possible I have not been clear.
>>>>> My understanding at the time was that by using something other than a void * different security modules could maintain their own opaque blobs with in and keep the same prototype for the hook.  It's possible I misunderstood you, but it made sense to me.  I don't know of any plans for other security modules to support Infiniband, but this leaves the door open.
>>>> All of what you describe above can still happen with a void pointer;
>>>> in some ways it is even easier with a void pointer.
>>> If multiple security modules register an alloc_security hook for example, how would you coordinate between them to allocate the memory?
>> You worry about that in the LSM framework and hide the details behind
>> the void pointer.  For example, you create an array/list of LSM
>> specific blobs and just stash a pointer to the head of the data in the
>> void pointer.
> Don't worry about it at this point. Patches pending.
> If I have to change modules to accommodate the
> infrastructure I'm not afraid to do so.

So I should revert to void* blobs?  I just want to be clear before making the change.

_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux