Wed Dec 22 05:00:46 2010: Request 63801 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: setuid pp'ed scripts: 1st invocation fails, 2nd+ call ok
Broken in: 1.008
Severity: Wishlist
Owner: Nobody
Requestors: bitc...@post2.25u.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63801 >
On 2010-12-21 10:56:00, arost wrote:
> Line 160 in Heavy.pm (version 0.12) is an open() statement in sub
> _dl_extract that requires write access.
Which - unfortunately - can't be helped for security reasons
(for the non-setuid usecase).
Archive::Unzip::Burst has probably done its job and extracted
Expat.so - but using its actual name (and path). However,
PAR::Heavy insists on looking for Expat.so first in the packed
executable (treated as a .par archive) and then extracts it
again using a mangled name.
Now, if one were to abandon the whole name mangling scheme...
> Or, as suggested before, maybe it's even better to
> make cache handling independent of the applications current effective
> user id. Which makes sense, since the cache handling (I think) is
> something that should be completely transparent to the application.
No, it doesn't make sense: the cache is per user (for a reason)
and YOU break transparency by "switching users" in midstream.
Sorry, but this not different from e.g. a script manipulating
@INC in nasty ways at runtime or invoking $^X.
> One last remark, maybe this is relevant: XML::SAX::Expat was added
> explicitly on the pp command line with
>
> -l "/usr/lib/libexpat.so" -M "XML::SAX::Expat"
No, that shouldn't make any difference. What matters is that
XML::SAX::Expat is loaded by your script at runtime (probably
required by XML::Simple or similar), instead of compile time
(i.e. via "use XML::SAX::Expat").
> So Steffen's workaround does not solve the cache ownership
> problem that exists when running pp'ed application via *sudo*.
Actually, it's not the use of sudo per se - it's your script
calling setuid at runtime.
Cheers, Roderich
Cheers, Roderich
