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