Wed Dec 22 06:24:46 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: bitc...@post2.25u.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=63801 >
On Wed Dec 22 05:00:46 2010, RSCHUPP wrote:
> On 2010-12-21 10:56:00, arost wrote:
> [...]
> > 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.
I don't agree to that. For @INC, I know that @INC can be subject to
external settings in the environment and that @INC affects the runtime
behaviour of my Perl application - so I know that I have to be careful fiddling
with that, no matter if pp'ed or not. Also for $^X, I'd _expect_ things
to be different in a pp'ed world.
setuid(), in contrast, is a systemcall like any other, which normally
has no impact on the behaviour of a Perl application (from a Perl point
of view), so in that sense, it is completely orthogonal to the world of
Perl. In the pp'ed Perl world, this is no longer true.
The per-user nature of caching I don't question at all - my suggestion is
rather to _enforce_ its per-user nature, by _always_ accessing the cache with
the
real user id, and _not_ taking into account any later changes to the
effective user id.
> Actually, it's not the use of sudo per se - it's your script
> calling setuid at runtime.
Yep. So, to summarize, pp users must be aware of these three
points then:
1/ do not use setuid
2/ do not use POSIX::setuid(), and do not modify $>/$)
3/ if 2/ cannot be avoided, then workaround the PAR cache problems by
a) use Archive::Unzip::Burst, and
b) explicitly require any "leftovers" before the first call
to setuid()
Cheers/alex
