linux-kernel - Re: [RFC][PATCH] audit: Simplify by assuming the callers socket buffer is large enough

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 04 Mar 2014 16:51:22 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	akpm@...ux-foundation.org
Cc:	ebiederm@...ssion.com, rgb@...hat.com, eparis@...hat.com,
	linux-audit@...hat.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH] audit: Simplify by assuming the callers socket
 buffer is large enough

From: Andrew Morton <akpm@...ux-foundation.org>
Date: Tue, 4 Mar 2014 13:30:04 -0800

> On Fri, 28 Feb 2014 20:50:19 -0800 ebiederm@...ssion.com (Eric W. Biederman) wrote:
> 
>> 
>> Modify audit_send_reply to directly use a non-blocking send and
>> to return an error on failure (if anyone cares).
>> 
>> Modify audit_list_rules_send to use audit_send_reply and give up
>> if we can not send a packet.
>> 
>> Merge audit_list_rules into iaudit_list_rules_send as the code
>> is now sufficiently simple to not justify to callers.
>> 
>> Kill audit_send_list, audit_send_reply_thread because using
>> a separate thread for replies is not needed when sending
>> packets syncrhonously.
> 
> Nothing much seems to be happening here?
> 
> In an earlier email you said "While reading through 3.14-rc1 I found a
> pretty siginficant mishandling of network namespaces in the recent
> audit changes." Were those recent audit changes a post-3.14 thing?  And
> what is the user-visible effect of the mishandling?

I took a quick look at this patch yesterday, and my only suspicion is
that threads are created currently by this code purely to cons up a
blockable context for the netlink code.

Perhaps it wants to avoid any netlink packet drops from being possible.

I'm not so sure.

Anyways, some investigation into perhaps figuring out the intentions of
the original implementation would be nice.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/