Re: [RFC PATCH ghak32 V2 09/13] audit: add containerid support for config/feature/user records

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

 



On Thu, Apr 19, 2018 at 8:31 AM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
> On 2018-04-18 21:27, Paul Moore wrote:
>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
>> > Add container ID auxiliary records to configuration change, feature set change
>> > and user generated standalone records.
>> >
>> > Signed-off-by: Richard Guy Briggs <rgb@xxxxxxxxxx>
>> > ---
>> >  kernel/audit.c       | 50 ++++++++++++++++++++++++++++++++++++++++----------
>> >  kernel/auditfilter.c |  5 ++++-
>> >  2 files changed, 44 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/kernel/audit.c b/kernel/audit.c
>> > index b238be5..08662b4 100644
>> > --- a/kernel/audit.c
>> > +++ b/kernel/audit.c
>> > @@ -400,8 +400,9 @@ static int audit_log_config_change(char *function_name, u32 new, u32 old,
>> >  {
>> >         struct audit_buffer *ab;
>> >         int rc = 0;
>> > +       struct audit_context *context = audit_alloc_local();
>>
>> We should be able to use current->audit_context here right?  If we
>> can't for every caller, perhaps we pass an audit_context as an
>> argument and only allocate a local context when the passed
>> audit_context is NULL.
>>
>> Also, if you're not comfortable always using current, just pass the
>> audit_context as you do with audit_log_common_recv_msg().
>
> As mentioned in the tree/watch/mark patch, this is all obsoleted by
> making the AUDIT_CONFIG_CHANGE record a SYSCALL auxiliary record.

You've known about my desire to connect records for quite some time.

> This review would have been more helpful a month and a half ago.

If you really want to sink to that level of discussion, better quality
patches from you would have been helpful too, that is the one of the
main reasons why it takes so long to review your code.  Let's keep the
commentary focused on the code, discussions like this aren't likely to
be helpful to anyone.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux