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=-4.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 F2DF0C282DA for ; Tue, 9 Apr 2019 13:41:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C41FA2070D for ; Tue, 9 Apr 2019 13:41:20 +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="YEhdK1Tr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727179AbfDINlM (ORCPT ); Tue, 9 Apr 2019 09:41:12 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:45447 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726129AbfDINlM (ORCPT ); Tue, 9 Apr 2019 09:41:12 -0400 Received: by mail-lj1-f194.google.com with SMTP id y6so14481557ljd.12 for ; Tue, 09 Apr 2019 06:41:10 -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=p3vyeIn43IG+brbHELRfPrc4NO3qJy22/cRNmBwEyGY=; b=YEhdK1Tr1X1VAi2x4C9Scm7lUUzJpv+938XjrX0A+cTfKoaFB+Q0mGB01QfJ4S14ca VPn67lqVFVG0ODvDCDcZyb4R6m5UJOkNTaEGIFDSQsUwtxX/CDULbZ7SCSE0Ou84AJpY RUYz7Yx2EnAna3gJwgWun8XzBOHLvMpLJS6O7MoeKDcDzT2tM/n+BHJkqFZyXOqAvGME UumFcqkYcqocGjGk/exUSNSDXNiF2aJyllsIeQCjLrGc7pzav2VZAzAv4sqE3rab0Lzi bkCutZuMsjQifi+XC6TwbGb2H4GKmwztZ1iCEg2mZeVEQILzFRKFrZrKJwS3VKvpHfft MfPw== 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=p3vyeIn43IG+brbHELRfPrc4NO3qJy22/cRNmBwEyGY=; b=EzoGmJvpged9h9XjfFNyHfr0OOIIokH1xTKp++i52L34AAnRV76mzcB9UR9NeKsh8O p0MPEjFfFR7NcjSxY0Dm7IbEw2fbwGlDTeLvPiHKj9HbdgyMmIOZRl0XJFZPUBXFv18J SIE81QjcQ0vQ6LxvvIftb5V6zg28rtLFIzHw52rz/8c/0/WCpM1BCw0u/fC2ctvYpiAg yOzOayZAImNrI42W2zm7UStd+3k5YHe9pXtbWa2S7Gr1DSPt1tKocszYePWyBpbHEpPZ oUv5HQl0yFFdGmCTrhmy3E1uRQNyIJTbqahqn79WdrnC07bDkkVQHuHvfGO1Xi1CtJ6Z ROeA== X-Gm-Message-State: APjAAAW3SYNsJlL5XMyTGk2JebXpMXRFOJxUBa5GKszb3gTOcIA4I6Tp sVuupnEsY1sDaMbIHaBv8ze374qTtj1rE7LXq2ZH X-Google-Smtp-Source: APXvYqxdHKPr+2RXagsy6oke+WsSror1Au2F3cfqo87dZHnTU7VnFYh0IZ+ojX7bGxfI2rP/TxrbFRMJ5Pcqi8JYG1I= X-Received: by 2002:a2e:9649:: with SMTP id z9mr2697569ljh.92.1554817269998; Tue, 09 Apr 2019 06:41:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Moore Date: Tue, 9 Apr 2019 09:40:58 -0400 Message-ID: Subject: Re: [PATCH ghak90 V6 05/10] audit: add contid support for signalling the audit daemon To: Ondrej Mosnacek 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, Steve Grubb , David Howells , Simo Sorce , Eric Paris , "Serge E. Hallyn" , "Eric W . Biederman" , nhorman@tuxdriver.com 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 Tue, Apr 9, 2019 at 8:58 AM Ondrej Mosnacek wrote: > > On Tue, Apr 9, 2019 at 5:40 AM Richard Guy Briggs wrote: > > Add audit container identifier support to the action of signalling the > > audit daemon. > > > > Since this would need to add an element to the audit_sig_info struct, > > a new record type AUDIT_SIGNAL_INFO2 was created with a new > > audit_sig_info2 struct. Corresponding support is required in the > > userspace code to reflect the new record request and reply type. > > An older userspace won't break since it won't know to request this > > record type. > > > > Signed-off-by: Richard Guy Briggs > > This looks good to me. > > Reviewed-by: Ondrej Mosnacek > > Although I'm wondering if we shouldn't try to future-proof the > AUDIT_SIGNAL_INFO2 format somehow, so that we don't need to add > another AUDIT_SIGNAL_INFO3 when the need arises to add yet-another > identifier to it... The simplest solution I can come up with is to add > a "version" field at the beginning (set to 2 initially), then v_len > at the beginning of data for version . But maybe this is too > complicated for too little gain... FWIW, I believe the long term solution to this is the fabled netlink attribute approach that we haven't talked about in some time, but I keep dreaming about (it has been mostly on the back burner becasue 1) time and 2) didn't want to impact the audit container ID work). While I'm not opposed to trying to make things like this a bit more robust by adding version fields and similar things, there are still so many (so very many) problems with the audit kernel/userspace interface that still need to be addressed. -- paul moore www.paul-moore.com