From: Etienne Basset <etienne.basset@numericable.fr>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: LSM <linux-security-module@vger.kernel.org>,
Eric Paris <eparis@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-audit@redhat.com
Subject: Re: [PATCH 2/2] security/smack implement logging V2
Date: Mon, 06 Apr 2009 08:17:40 +0200 [thread overview]
Message-ID: <49D99E84.3000708@numericable.fr> (raw)
In-Reply-To: <49D966DB.9070009@schaufler-ca.com>
Casey Schaufler wrote:
> Etienne Basset wrote:
>>> It looks like the only difference between these are their non-logging
>>> versions is the logging. I say go ahead and add the auditdata parameter
>>> to smk_access and smk_curacc and allow for the case where it is NULL.
>>>
>>>
>> i would prefer keeping a logging and a non-logging variant
>> maybe rename smk_access & smk_curacc to smk_access_nolog & smk_curacc_nolog
>> Or you really prefer that we pass a NULL when we want the non-logging?
>> I guess its a matter of taste, so i let you decide :)
>>
>
> I dislike functions that do nothing but set up another function.
>
>
fair enough
>>> It would be nice if audit data was only manipulated if audit is
>>> installed, but I don't like the idea of ifdeffing everything
>>> very much either. How about a static inline in smack.h that is
>>> ifdeffed for audit? smack_audit_init? There would need to be one
>>> for each field, too.
>>>
>>>
>> why not, but instead of a "initialiser" for each field i'll prefer a macro
>> To save some stack we could also conditionnaly define the "common_audit_data"
>>
>> something like :
>>
>> #ifdef CONFIG_AUDIT
>> #define DEFINE_SMACK_AUDIT_DATA(ad) struct common_audit_data ad
>> void smack_audit_init(..) {
>> COMMON_AUDIT_DATA_INIT(...)
>> }
>> #define SMACK_AUDIT_DATA_SET_FIELD(_ad, _field, _value) (_ad._field = _value)
>> ...
>> #else
>> #define DEFINE_SMACK_AUDIT_DATA(ad)
>> void smack_audit_init(..)
>> {
>> }
>> #define SMACK_AUDIT_DATA_SET_FIELD(_ad, _field, _value)
>> #endif
>>
>
> I'm not convinced. #defines are good for assigning names to constants,
> but I saw the original Bourne shell code, where defines were used to
> make the code look like ALGOL68, so you have to overcome the fear that
> was instilled in me when I was young.
>
>
hum... it's already everywhere :)
to save stack space in the NON-AUDIT case, maybe something like :
struct smk_audit_data {
#ifdef CONFIG_AUDIT
struct common_audit_data;
#endif
}
(which i don't really like either, but we have to find a compromise between
"bloat" in the NON-AUDIT case and clean-looking code)
sure, i could make the "initialisers" static inline, the only downside is more C code
(and more homework for me ;) )
>
>>> Now this is tricky. You'll get an audit record for single-label
>>> hosts, but not for those that use CIPSO. The former is good, the
>>> latter is bad.
>>>
>>>
>> gargll you're right
>>
>
> I love those french idioms.
>
:)
> Actually, I don't think there's much point in worrying about it.
> The audit you do here is correct, and until you can get more subject
> information over the wire there isn't much point doing it on the
> receiving end.
>
ok
thanks
Etienne
prev parent reply other threads:[~2009-04-06 6:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-05 8:47 [PATCH 2/2] security/smack implement logging V2 Etienne Basset
2009-04-05 17:49 ` Casey Schaufler
2009-04-05 20:42 ` Etienne Basset
2009-04-06 2:20 ` Casey Schaufler
2009-04-06 6:17 ` Etienne Basset [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D99E84.3000708@numericable.fr \
--to=etienne.basset@numericable.fr \
--cc=casey@schaufler-ca.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox