From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A89BC28CC0 for ; Thu, 30 May 2019 13:35:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5423A259C6 for ; Thu, 30 May 2019 13:35:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.b="PcjCE05V" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727100AbfE3Nfv (ORCPT ); Thu, 30 May 2019 09:35:51 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:42102 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727036AbfE3Nfv (ORCPT ); Thu, 30 May 2019 09:35:51 -0400 Received: by mail-lj1-f194.google.com with SMTP id y15so2860948ljd.9 for ; Thu, 30 May 2019 06:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/U1f8Fc02eyDkuGsWIDz5srojNJJU/zoTrLNm2qEEYE=; b=PcjCE05Vr6571Z0FZcLJcqv+cvaAJeL7YpbARuQ2LSZIHBxhkDAdsF9jD7NhDOKngU 6X1SX5q77QkN9n3E19d4YHs9c0CtfyLSRuUuSdOXluMQYnqok+2LuhQnfV6Yvt5gokXc rv1Y97UwU29b5+KdfE/UeKLzGLNovyUXymuMuyGyAd1g6N0pG2/4sWOP2UBIUSzYLfHX V1r+bdOV/ByhYIvgWgk1An0M77FfT6aJutWDNqmHH2KjEzC70mCUzzpod9jb6FNa/AtR MEO9qpdFx+xNcpWYtV4mCZ49HXeovOfghdnPjt29AHlHiv/t+7uoYA1WS7kIwbDGPK1R tWhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/U1f8Fc02eyDkuGsWIDz5srojNJJU/zoTrLNm2qEEYE=; b=XQLQ1AfZqBGBLaw7yoEJiELem+fM2chRIBjb651zUlS62hzlaiYf+dGBWaDvckcZUm zx16gpW288pFcouTrNxt2p7TkdkxVsNxOOOpGM/stImKQCs6aiBgvDki54J+aRxPpUE0 Co939hND9H59Phfc9ocEbu6ybN/m9NYhS3W8HFMTt8PwVINdW9zEVCxNjNe0E4pl4d/C skRkvdTJdx+jwiT9vz4lCHGOEHTs1si+cxF4pgnKeNU7uLielKAOwHi75C7fxI2xPJKN FipT7/gdaBDaBk87g5XISW0PafFGReNGB3SXyFksLsNuftMRlZB62GZbEXKj+8IqGqHl szEA== X-Gm-Message-State: APjAAAVaPiZ2IUlykWJuXGcOEORJkC36P0QCuXusG4qypKZ7Aemk4JW3 HNOeyKl83CyYb/mqrlImCAkRDab2+tt3QYnmuYi8 X-Google-Smtp-Source: APXvYqxLKiEME9EKDe015SLMtCLzjMQupiY0eTQcPEupXRnKhW/v5gEX9weuoubW+5N0jXscBR8tMiamdrFu8nfWc0w= X-Received: by 2002:a2e:3e14:: with SMTP id l20mr2252084lja.40.1559223348494; Thu, 30 May 2019 06:35:48 -0700 (PDT) MIME-Version: 1.0 References: <1674888.6UpDe63hFX@x2> In-Reply-To: <1674888.6UpDe63hFX@x2> From: Paul Moore Date: Thu, 30 May 2019 09:35:36 -0400 Message-ID: Subject: Re: [PATCH ghak90 V6 00/10] audit: implement container identifier To: Steve Grubb Cc: Richard Guy Briggs , containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, omosnace@redhat.com, dhowells@redhat.com, simo@redhat.com, Eric Paris , Serge Hallyn , ebiederm@xmission.com, Neil Horman Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, May 30, 2019 at 9:08 AM Steve Grubb wrote: > On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote: > > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore wrote: > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman > wrote: > > > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > > > Implement kernel audit container identifier. > > > > > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we > > > > good for inclusion? > > > > > > I haven't finished going through this latest revision, but unless > > > Richard made any significant changes outside of the feedback from the > > > v5 patchset I'm guessing we are "close". > > > > > > Based on discussions Richard and I had some time ago, I have always > > > envisioned the plan as being get the kernel patchset, tests, docs > > > ready (which Richard has been doing) and then run the actual > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > to make sure the actual implementation is sane from their perspective. > > > They've already seen the design, so I'm not expecting any real > > > surprises here, but sometimes opinions change when they have actual > > > code in front of them to play with and review. > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > whatever additional testing we can do would be a big win. I'm > > > thinking I'll pull it into a separate branch in the audit tree > > > (audit/working-container ?) and include that in my secnext kernels > > > that I build/test on a regular basis; this is also a handy way to keep > > > it based against the current audit/next branch. If any changes are > > > needed Richard can either chose to base those changes on audit/next or > > > the separate audit container ID branch; that's up to him. I've done > > > this with other big changes in other trees, e.g. SELinux, and it has > > > worked well to get some extra testing in and keep the patchset "merge > > > ready" while others outside the subsystem look things over. > > > > I just sent my feedback on the v6 patchset, and it's small: basically > > three patches with "one-liner" changes needed. > > > > Richard, it's your call on how you want to proceed from here. You can > > post a v7 incorporating the feedback, or since the tweaks are so > > minor, you can post fixup patches; the former being more > > comprehensive, the later being quicker to review and digest. > > Regardless of that, while we are waiting on a prototype from the > > container folks, I think it would be good to pull this into a working > > branch in the audit repo (as mentioned above), unless you would prefer > > to keep it as a patchset on the mailing list? > > Personally, I'd like to see this on a branch so that it's easier to build a > kernel locally for testing. FWIW, if Richard does prefer for me to pull it into a working branch I plan to include it in my secnext builds both to make it easier to test regularly and to make the changes available to people who don't want to build their own kernel. * http://www.paul-moore.com/blog/d/2019/04/kernel_secnext_repo.html -- paul moore www.paul-moore.com