On Wed, May 17, 2017 at 9:04 AM, William Roberts <bill.c.roberts@xxxxxxxxx> wrote: > On Wed, May 17, 2017 at 8:43 AM, Sebastien Buisson > <sbuisson.ddn@xxxxxxxxx> wrote: >> 2017-05-17 17:34 GMT+02:00 William Roberts <bill.c.roberts@xxxxxxxxx>: >>>>>>> Is there a particular reason to not just return policybrief_len here as >>>>>>> well, for consistency in the interface? How do you intend to use this >>>>>>> value in the caller? >>>>>> >>>>>> As called in the other patch to expose policy brief via selinuxfs >>>>>> (sel_read_policybrief), the intent is to provide the caller with the >>>>>> length of the string returned. >>>>>> Or should I set *len to policy brief_len here, and just make the >>>>>> caller aware that the returned length is in fact the length of the >>>>>> buffer (i.e. including terminating NUL byte)? >>>>> >>>>> What is the caller supposed to do with length? This interface seemed kind of >>>>> odd. If it's guaranteed NUL byte terminated, do they even need length? >>>> >>>> The length is useful as an input parameter in case the caller provides >>>> its own buffer (instead of letting the function allocate one), and as >>> >>> This is what I don't get, why doesn't the function just always allocate? >> >> For performance reasons mainly. The caller would have a statically >> allocated buffer, reused every time it needs to get the policy brief >> info. > > I'm assuming in the Lustre code you're going to call security_policy_brief(), > how would the caller know how big that buffer is going to be? > > I'm looking at both v5 patches, I don't see where it's being called with alloc > set to false. > > I don't see how this works with LSM stacking, I would imagine the security > hook needs to call this routine for each LSM and join them together in > some module name spaced way, which was mentioned before, but I don't > see that either, am I missing it? Disregard this last statement, I thought more of stacking was in.
