Mon Dec 20 06:28:54 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 Sun Dec 19 11:16:26 2010, RSCHUPP wrote:
>
> As I already wrote in #62552, packed executables are not
> meant to be run setuid and - as far as I'm concerned -
> never will be. So don't do that then.
This fact is clear now, thanks.
I don't understand the rationale, though - to users of the pp
"compiler", this sounds like the gcc people saying that they don't care
about gcc generating broken setuid binaries, since they cannot guarantee
that gcc does not introduce security leaks in such binaries. Some
background would be helpful here also for others who discover that pp
does not support setuid execution.
In any case: I do appreciate your contribution to this tremendously
useful package, so no need to argue here. We will try switching to sudo
now (but, read on please, since there may be similar problems with
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>
2/ but the owner of the cache entries is root
3/ it seems that PAR tries to put some file into the cache at a later
point during the program's lifetime
4/ but if the effective user id is not root at that time, then this
*fails* due to "2".
Making the cache world-writable fixes the problem under 4/, and the
pp'ed program runs fine even though it's setuid root.
It looks like a rather straightforward solution for this is to ensure
that any cache files will *always* be read and written with the *real
user id*, not the effective one.
If this is not the case, then also users of sudo (who switch the
effective user id in their program) will run into the same problem,
since the cache belongs to root, and it's not writeable by non-root
users.
Cheers/alex
