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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 06 Sep 2007 10:31:03 +0100
From:	James Pearson <james-p@...ing-picture.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Anton Arapov <aarapov@...hat.com>,
	Guy Streeter <guy.streeter@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: 4096 byte limit to /proc/PID/environ ?

Alexey Dobriyan wrote:
> On Wed, Sep 05, 2007 at 06:00:57PM +0100, James Pearson wrote:
> 
>>H. Peter Anvin wrote:
>>
>>>Anton Arapov wrote:
>>>
>>>
>>>> Hey guys, the future of this patch is important for me. What do you 
>>>>think, has this patch any chances to be committed to upstream?
>>>>
>>>>James Pearson <james-p@...ing-picture.com> writes:
>>>>
>>>>
>>>>>H. Peter Anvin wrote:
>>>>>There isn't that much that is duplicated - and there are also bits of
>>>>>the /proc/PID/mem code that are not needed in this case, so I'm not
>>>>>really sure if it is worth doing.
>>>>>
>>>>>I did submit a patch a few months ago - see:
>>>>>
>>>>><http://marc.info/?l=linux-kernel&m=117862109623007&w=2>
>>>>
>>>>
>>>Looks reasonable to me, except for the one overlong line.
>>>
>>
>>OK, here is the patch (without the long line) against 2.6.23-rc5 - what 
>>else needs to be done to get it committed?
> 
> 
> Remove duplicate ptrace_may_attach() checks, unecessary (), {} and
> spaces before pointer names -- char *buf.

environ_read() in the patch uses ptrace_may_attach() in a similar way as 
does mem_read(). Given that environ_read() is based on mem_read(), does 
this mean that duplicate ptrace_may_attach() checks need to be removed 
from mem_read() as well? Which ptrace_may_attach() needs to be removed?

Thanks

James Pearson
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ