At 10:44 AM -0600 3/20/07, Mark Berryman wrote:
>Craig A. Berry wrote:
>>At 8:36 PM -0600 3/18/07, Mark Berryman wrote:
>>
>>>Craig A. Berry wrote:
>>>
>>>>A protected subsystem
>>>>identifier can trigger tainting more or less like running with -T on
>>>>the command line.
>>>>
>>>>
>>>That was the ticket. The process on the malfunctioning system has a
>>>protected subsystem rights identifier that does not exist on the working
>>>system. That being the case, what is the fix? Removing that rights
>>>identifier is not really an option.
>>>
>>
>>If what you are doing is building extensions, then perhaps you could
>>build and install them using a different account from the one that
>>has the subsystem identifier. You might still run into trouble
>>running scripts, but there is really no way around that without
>>either following the tainting rules or hacking out the security
>>model. Read more about tainting in perlsec.pod.
>>
>If the problem only happened when building extensions then, yes, there would
>be a simple workaround. However, to my knowledge, I am not violating any
>tainting rules. For example, something as simple as the following will abort
>simply because the process issuing it owns a subsystem rights identifier:
>
>$ perl -"MExtUtils::Installed" -e -
>_$ "$m=ExtUtils::Installed->new(); print join qq{\n}, $m->modules();"
>
>Insecure dependency in chdir while running with -T switch at
>/perl_root/lib/File/Find.pm line 832.
>%RMS-E-DNF, directory not found
>-NONAME-W-NOMSG, Message number 00000000
And it will do the same thing with the -T switch on the command line
even without the rights identifier there.
>
>Delete that rights identifier (which is not in any way used or referenced by
>the above command) and the command executes without issue. This sounds like a
>bug in Perl to me.
>I get random aborts when running perl scripts and it turns out to be caused by
>whether or not the user running the script has been granted a subsystem rights
>identifier. I can't delete the rights but I do need the perl scripts to work.
Perl has no way of knowing whether the identifier is referenced or
used. Whether it could acquire that capability is not something I've
ever looked into, but it would probably require many changes
throughout the Perl sources rather than one fairly simple check at
start-up time.
Basically subsystem identifiers are considered the equivalent of
running with setuid or setgid under unix. You are able to get at
something you are not the owner of and that you don't have other
means of accessing except through this special means. So that's why
tainting is enabled.
I'm probably the last person in the world who should attempt to
explain tainting, but as I understand it, it's a way of preventing
anything from the outside world gaining insecure access to something
in the inside world. File::Find is crawling all over the file system
and taking actions based on what it turns up; it can't be run with
tainting enabled under any OS, not just VMS. Here is your example on
Mac OS X with the -T switch explicitly enabling taint mode:
% perl -T -MExtUtils::Installed -e '$m=ExtUtils::Installed->new(); print join
qq{\n}, $m->modules();'
Insecure $ENV{PATH} while running with -T switch at
/usr/local/ActivePerl-5.8/lib/ActivePerl/Config.pm line 128.
Compilation failed in require at
/usr/local/ActivePerl-5.8/lib/ExtUtils/MakeMaker.pm line 7.
BEGIN failed--compilation aborted at
/usr/local/ActivePerl-5.8/lib/ExtUtils/MakeMaker.pm line 7.
Compilation failed in require at
/usr/local/ActivePerl-5.8/lib/ExtUtils/Installed.pm line 7.
BEGIN failed--compilation aborted at
/usr/local/ActivePerl-5.8/lib/ExtUtils/Installed.pm line 7.
Compilation failed in require.
BEGIN failed--compilation aborted.
So it actually dies on an environment issue before it even gets to the chdir
issue.
I wish I had something easier or simpler to suggest. The current
behavior is there by design and has been the way it is for a decade
or more, so I wouldn't expect it to change.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
