Tue Dec 21 10:56:00 2010: Request 63801 was acted upon.
Transaction: Correspondence added by arost
       Queue: PAR-Packer
     Subject: setuid pp'ed scripts: 1st invocation fails, 2nd+ call ok
   Broken in: 1.008
    Severity: Wishlist
       Owner: Nobody
  Requestors: [email protected]
      Status: open
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63801 >


On Mon Dec 20 17:53:46 2010, SMUELLER wrote:
> 
> On Dec 20, 2010, at 2:24 PM, Alexander Ost via RT wrote:
> [...]
> > a) any way to "request" that the whole archive is extracted
> *completely* into the cache?
> [...]
> Try installing Archive::Unzip::Burst on the dev machine. If it
> succeeds, it will be packed into the executable and everything will be
> extracted on the first invocation.

Thanks for the hint. Ironically, even though I switched to using sudo
now, this fixes the setuid problem posted originally for this bug.

However, for setuid, this doesn't solve the problem
completely. Starting my application (including "use
Archive::Unzip::Burst") via sudo, I get the following error in the
middle of the execution:

  Permission denied at /home/builder/.lib/perl-5.10.0-
nt/lib/site_perl/5.10.0/PAR/Heavy.pm line 160.
  Compilation failed in require at XML/Parser.pm line 18.
  BEGIN failed--compilation aborted at XML/Parser.pm line 22.
  Compilation failed in require at XML/SAX/Expat.pm line 11.
  BEGIN failed--compilation aborted at XML/SAX/Expat.pm line 11.
  Compilation failed in require at (eval 71) line 1.

Line 160 in Heavy.pm (version 0.12) is an open() statement in sub
_dl_extract that requires write access.

To find the culprit, I made the PAR cache world writeable and started
over. After that the application runs fine, and one file has been
added to the cache. That file corresponds to

  lib/site_perl/5.10.0/i686-linux-thread-
multi/auto/XML/Parser/Expat/Expat.so

So this file hasn't been extracted at the beginning, and later on,
extraction fails, because in the meantime the application has dropped
root priviledges.

I could now work around this by explicitly require-ing XML::SAX::Expat
at the very beginning of the main module, but this is no general
solution of course.

Would there be any way to enforce a (really) complete "unpack" at the
very beginning? 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.

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"


Thanks again for your help,
/alex

Reply via email to