From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 4th revision] Add SELinux context support to AUDIT target Date: Thu, 30 Jun 2011 13:35:10 +0200 Message-ID: <4E0C5F6E.4000005@trash.net> References: <4DF9C085.3040306@googlemail.com> <4DFC9525.2080402@googlemail.com> <201106200820.23127.sgrubb@redhat.com> <4DFF5783.3070808@googlemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org To: Eric Paris Cc: Mr Dash Four , Steve Grubb , linux-audit@redhat.com, netfilter-devel@vger.kernel.org, Thomas Graf , Al Viro , Pablo Neira Ayuso List-Id: linux-audit@redhat.com Am 20.06.2011 16:27, schrieb Eric Paris: > On Mon, Jun 20, 2011 at 10:21 AM, Mr Dash Four > wrote: >> > >>> >> Do you think this should be hardcoded to be obj? Would we ever log the >>> >> subj? Or should obj be part of the function name to make it clear which >>> >> piece is getting logged? >>> >> >> > >> > I thought of that, though I don't know what variety of option names would be >> > there to be used with that function. >> > >> > If there is a need to use something other than "obj", like, "subj" or even >> > "tcontext" or "scontext" for example, then I would favour passing the option >> > name as function parameter - something like "void audit_log_secctx(struct >> > audit_buffer *ab, char *secname, u32 secid)" or even "void >> > audit_log_secctx(struct audit_buffer *ab, int secname, u32 secid)" (secname >> > here being one of 0, 1, 2 ... corresponding to "obj", "subj" etc). >> > >> > Similar approach is already used in audit.c - in audit_log_config_change for >> > example: >> > >> > static int audit_log_config_change(char *function_name, int new, int old, >> > uid_t loginuid, u32 sessionid, u32 sid, int allow_changes) >> > { >> > struct audit_buffer *ab; >> > int rc = 0; >> > >> > ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE); >> > audit_log_format(ab, "%s=%d old=%d auid=%u ses=%u", function_name, new, >> > old, loginuid, sessionid); > Hard code for now. %s in audit record building is the devil since > there is no enforcement of audit's rather 'special' string encoding > rules. If we need another name later we'll cross that bridge when we > get there, possibly with another helper function and pushing the %s to > a static function inside audit. I will not willing expose %s to code > outside of audit.c. > > Acked-by: Eric Paris > Applied, thanks. I had to fix some overly long lines and whitespace errors in the patch and the commit message to contain a subject and not have the entire text contained in two lines. Please be more careful of this next time.