Mon Dec 20 07:51:04 2010: Request 63801 was acted upon.
Transaction: Correspondence added by roderich.sch...@googlemail.com
Queue: PAR-Packer
Subject: Re: [rt.cpan.org #63801] 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 Mon, Dec 20, 2010 at 12:28 PM, Alexander Ost via RT
<bug-par-pac...@rt.cpan.org> wrote:
> I don't understand the rationale, though - to users of the pp
My thinking here is: The packed executable should strive to exhibit the
same behaviour as the original perl script.
I have no problem with people writing setuid scripts that have
security problems. But a packed executable uses several Perl modules
internally (i.e. unaware to user) and all these and their usage would have
to be audited not to introduce _additional_ security problems.
Moreover, the packed executable uses a custom Perl interpreter
with a small C prologue and that would have to be audited as well.
Especially cumbersome is the bootstrap process (the packed
executable extracts another executable and then execs that).
> As a matter of fact, pp'ed binaries _do_ run setuid, they just suffer
> from some rather smaller glitches resulting from ownership of cached
> files. I wonder if those problems will also appear when running a pp'ed
> program via sudo (and then changing the effective user id during
> execution):
> 1/ cache directory is created as /tmp/par-<real username>
Yeah, but you can overwite the name of the cache directory
(PAR_GLOBAL_TMPDIR IIRC).
> 3/ it seems that PAR tries to put some file into the cache at a later
> point during the program's lifetime
Correct. Some stuff will only be extracted on demand.
> Making the cache world-writable fixes the problem under 4/, and the
Thereby creating a security hole you can drive an aicraft carrier through.
Cheers, Roderich
