Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3884216yba; Tue, 9 Apr 2019 06:50:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqzcoawgsF6dxu4ZUoiddPepbm0E/feRvrvw7+vadPfBxHJEkuOP8OcwoL670f5bQgN8DKhz X-Received: by 2002:a17:902:2f43:: with SMTP id s61mr15574990plb.181.1554817826255; Tue, 09 Apr 2019 06:50:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554817826; cv=none; d=google.com; s=arc-20160816; b=dWBi34Nmlyp0TEa8OxAHiXYAg87+pUutScPN+Wq5ES2i5elkIkAUHvahhGwHfG6o3B LsUodDj0bVgK/Lg9h8d87y1nwT4ySWBhofFKvGAPVKLbdvYTkt9IbdmvbEsvynBiudS8 LcH1A/IcrPk/2HAujVoucsNJj9JOvbR0l+METd1Lpc7KrMfShwKx7BSLdX/4BLT2H0QR 1rpQIURxAeYi1U3hL8iyQJNUjpKKF2RsgNXV/1DuTMo7l28CwJVAP4fBYVZlv4go1Vbz x1B5JlxXyF0c6HRxbi85akrX1xV2VPFDfXCpsCFvAXtHLwv72qWDninv9sNh8uiDQS2u Orpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=nOdzrGMAajK1rxzx7rPGO3efgMOPoNYVGk3j+hFE8+c=; b=WqWojEjJP3zs/a7PN1RhsTMalYHpHgglkGLU3EHRABJqQir0yz8FjuDhWRSKlCv7z9 LC1icYqn1mWgiZoQeZDvJ4d906rmi4RD2gDiQWLON7biR61ICPQA9I6MYeBZzLZMyWHa JZDaxyo7OPZew6wXW0rhQoV0tDcYqBH4qOeOKqTYlcJ4FqCD79fcHM/eyC32LDcmE5+y vuX55UAEFs0pRtpCNfGn5MD3hnuHpWaIYfgxEIrMRe8bR+/cO2puIa6xKig3YtkPXX7Y KbhKbobWDdSeJIBud5KPiTj7tm4u9XGYiYPmqDxVHGiuySL/3vKlVYRcVja2AznBRQVM 0HJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l4si17829577pgp.280.2019.04.09.06.50.09; Tue, 09 Apr 2019 06:50:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726492AbfDINtb (ORCPT + 99 others); Tue, 9 Apr 2019 09:49:31 -0400 Received: from charlotte.tuxdriver.com ([70.61.120.58]:32966 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbfDINtb (ORCPT ); Tue, 9 Apr 2019 09:49:31 -0400 Received: from cpe-2606-a000-111b-405a-0-0-0-188a.dyn6.twc.com ([2606:a000:111b:405a::188a] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1hDr7p-00012u-Dr; Tue, 09 Apr 2019 09:49:23 -0400 Date: Tue, 9 Apr 2019 09:48:52 -0400 From: Neil Horman To: Paul Moore Cc: Ondrej Mosnacek , 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" Subject: Re: [PATCH ghak90 V6 05/10] audit: add contid support for signalling the audit daemon Message-ID: <20190409134852.GB15660@hmswarspite.think-freely.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Score: -2.9 (--) X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 09, 2019 at 09:40:58AM -0400, Paul Moore wrote: > 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. > Agreed, this change as-is is in keeping with the message structure that audit has today, and so is ok with me, but the long term goal should be a conversion to netlink attributes for all audit messages. Thats a big undertaking and should be addressed separately though. Neil > -- > paul moore > www.paul-moore.com >