develooper Front page | perl.perl5.porters | Postings from August 2008

RE: [PATCH] Safer environ iteration

Thread Previous
From:
Milosz Tanski
Date:
August 6, 2008 08:57
Subject:
RE: [PATCH] Safer environ iteration
Message ID:
C0A5E31718FC064A91E9FD7BE2F081B1018A225F@exchange.gridapp.com
Yes this behavior will not be exhibited in stand alone perl, and will
only crop up when embedding perl interpreters in multi-threaded apps.
This is actually the case with us, sorry for not making this clear in
the original email.

Thanks,
-- Milosz

-----Original Message-----
From: Rafael Garcia-Suarez [mailto:rgarciasuarez@gmail.com] 
Sent: Wednesday, August 06, 2008 3:32 AM
To: Milosz Tanski
Cc: perl5-porters@perl.org
Subject: Re: [PATCH] Safer environ iteration

2008/8/6 Milosz Tanski <mtanski@gridapp.com>:
> The code in S_init_postdump_symbols that iterates over the environ 
> array dereferences the pointer to the current element every operation 
> in that for block, which leads to a race condition.

Without looking at the code, I have a question : I thought this was a
solved problem, at least with perls compiled without
-DPERL_USE_SAFE_PUTENV in the ccflags ? So your patch actually applies
only to those perls (usually embedded perls ?)

> Example:
>
>  thread 1:
>    in for loop looking at env var: FOO_VAR
>    saved '=' character address in s
>
>  thread 2:
>    doing putenv for FOO_VAR
>
>  thread 1:
>    back in the same iteration of the for loop (still FOO_VAR):
>    (void)hv_store(hv, *env, s - *env, sv, 0);
>
> There's a possibility that in between us saving the address of '=' 
> char and doing hv_store the value of *env changes to a new address. 
> And then we can be allocating a really large memory block or a 
> negative one. Both of those are good reason for Perl malloc to croak 
> and a call like perl_parse might fail with an "Out of memory!" message

> printed to stderr.
>
> I attached a patch that makes a copy of *env before each iteration 
> instead of dereferencing env at every single operation. This relies on

> the agreed upon behavior to never free any memory allocated for vars 
> in environ, just dropping the old values on the floor (and it'll get 
> freed
> exit) when replacing an element of environ. This is the behavior for 
> putenv/setenv on Linux, Solaris and HP-UX and possibly others. While 
> this won't fix the issue on systems that don't conform to this 
> behavior but it'll work a lot better in the corner cases on those 
> systems that handle it properly.
>
> Cheers,
> -- Milosz
>



--
'Do you know what they called a sausage-in-a-bun in Quirm?' said Mr Pin,
as the two walked away. --- 'No?' said Mr Tulip. --- 'They called it "le
sausage-in-le-bun".' -- Terry Pratchett, The Truth

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About