Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1643498
| From | William Roberts <bill.c.roberts@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v5 1/2] selinux: add brief info to policydb |
| Date | 2017-05-17 18:30 +0200 |
| Message-ID | <tI9ZL-5oT-9@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <tI8Km-4GH-19@gated-at.bofh.it> <tI93I-4Nh-13@gated-at.bofh.it> <tI9dn-4QL-11@gated-at.bofh.it> <tI9n3-4Ud-9@gated-at.bofh.it> <tI9Gq-5g6-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, May 17, 2017 at 9:04 AM, William Roberts <bill.c.roberts@gmail.com> wrote: > On Wed, May 17, 2017 at 8:43 AM, Sebastien Buisson > <sbuisson.ddn@gmail.com> wrote: >> 2017-05-17 17:34 GMT+02:00 William Roberts <bill.c.roberts@gmail.com>: >>>>>>> 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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v5 1/2] selinux: add brief info to policydb Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-05-16 12:00 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb Stephen Smalley <sds@tycho.nsa.gov> - 2017-05-16 22:40 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-05-17 17:10 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb William Roberts <bill.c.roberts@gmail.com> - 2017-05-17 17:10 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-05-17 17:30 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb William Roberts <bill.c.roberts@gmail.com> - 2017-05-17 17:40 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-05-17 17:50 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb William Roberts <bill.c.roberts@gmail.com> - 2017-05-17 18:10 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb William Roberts <bill.c.roberts@gmail.com> - 2017-05-17 18:30 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-05-17 19:10 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb William Roberts <bill.c.roberts@gmail.com> - 2017-05-17 20:30 +0200
Re: [PATCH v5 1/2] selinux: add brief info to policydb Stephen Smalley <sds@tycho.nsa.gov> - 2017-05-17 17:40 +0200
csiph-web