-
Notifications
You must be signed in to change notification settings - Fork 555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use lib segmentation fault #4206
Comments
From aldrsh@meappdev.micro.lucent.comCreated by bplatz@us.ibm.comThis is a bug report for perl from bplatz@us.ibm.com, ----------------------------------------------------------------- After installing Perl 5.6.1, the following Perl script generates a segmentation # start of script: BEGIN # use File::Basename; # use lib $ENV{LMEPDM_LIB}; system("id"); The above runs fine under Perl 5.004. I found that if I replace the variable reference in the Example: use lib "/home/mxweb/lib"; I also found that the above script will work fine under 5.6.1 if I leave I would appreciate any assistance you might be able to provide if this is Thanks in advance, Perl Info
|
From [Unknown Contact. See original ticket]Dear Perl Bug Administrators, please update the "sent from" information for Thanks in advance, |
From [Unknown Contact. See original ticket]Thanks again, |
From [Unknown Contact. See original ticket]Is anyone monitoring email sent to perlbug@perl.org? Back in July I I would greatly appreciate it if someone could please respond to this bug Thanks in advance, |
From [Unknown Contact. See original ticket]Created by bplatz@us.ibm.comThis fellow feels like he's being ignored. He sent the message in July, it recieved a bugid, and both it and his TIA Ciao -------- Original Message -------- Richard, below is a bug report that I submitted back on 7/13 regarding a I did not know what action to take. I noticed your name appear when I would really like to take advantage of some of the new features in Thanks in advance for any assistance you can provide. ----- Forwarded by David Schulte/Allentown/IBM on 11/08/2001 03:51 PM Your e-mail has been received by the Perl Bug Squashing Team. Original subject: use lib segmentation fault A Bug ID (20010713.001) has been assigned and is shown in the subject of This is an automatic confirmation message. If you do not wish to receive this confirmation, in the future, -- ---------------------------------------------------------------------------------------------------- This is a bug report for perl from bplatz@us.ibm.com, ----------------------------------------------------------------- After installing Perl 5.6.1, the following Perl script generates a # start of script: BEGIN # use File::Basename; # use lib $ENV{LMEPDM_LIB}; system("id"); The above runs fine under Perl 5.004. I found that if I replace the variable reference in the Example: use lib "/home/mxweb/lib"; I also found that the above script will work fine under 5.6.1 if I leave I would appreciate any assistance you might be able to provide if this Thanks in advance, Perl Info
|
From @rspier I am unable to replicate your segfault bug on a Solaris 8 machine, Could you compile a debugging version of perl (as per the Also, you may wish to try your test in one of the recent -R [bug details snipped] |
From @rspierNo, I didn't test in that case. I missed it in the bugreport. I It's possible that this bug might also be related to something you
See above. Ok. -R |
From @rspierThe stack trace is more than a little scary, but I'll see if I can -R Program received signal SIGSEGV, Segmentation fault. #0 0x080b13ff in Perl_mg_get (sv=0x81b925c) at mg.c:113 David Schulte writes:
-- |
From [Unknown Contact. See original ticket]Please let me know if you did the above. In the meantime, I'm recompiling a Thanks, |
From [Unknown Contact. See original ticket] |
From [Unknown Contact. See original ticket] |
From [Unknown Contact. See original ticket]I REALLY appreciate your efforts in digging into this problem!! |
From @rspier--- snip --- At the moment, it looks like the problem is in some interaction This is a segfault that should probably be eliminated, but David, you -R David Schulte writes:
-- |
From [Unknown Contact. See original ticket]While reading the configuration files, we need the effective uid changed For our code to be portable, we determine where our local Perl library Given that we set $PATH and $IFS explicitly, I figured we "should" be safe Even the simple example I provided with my original bug report complains Please let me know if you have any suggestions or documentation that I Thanks, |
From [Unknown Contact. See original ticket]As a workaround for the core dump, if the following patches won't be If the source code is loaded from a tainted path everything from that The first patch, against bleadperl, cures the segfault. It is mostly a The workaround may look too dangerous, but perl is already running in The second patch is for perl 5.6.x if you decide that the idea is Thank you, Inline Patch--- pp_ctl.c~ Sun Nov 4 04:35:19 2001
+++ pp_ctl.c Wed Nov 14 19:04:34 2001
@@ -3038,6 +3038,7 @@
SV *hook_sv = 0;
SV *encoding;
OP *op;
+ bool tainted;
sv = POPs;
if (SvNIOKp(sv)) {
@@ -3147,6 +3148,8 @@
for (i = 0; i <= AvFILL(ar); i++) {
SV *dirsv = *av_fetch(ar, i, TRUE);
+ TAINT_NOT; /* must clear taintedness after previous
+ possibly tainted entry */
if (SvROK(dirsv)) {
int count;
SV *loader = dirsv;
@@ -3386,11 +3389,17 @@
encoding = PL_encoding;
PL_encoding = Nullsv;
+ tainted = PL_tainted;
+ if (PL_unsafe)
+ TAINT_NOT;
+
op = DOCATCH(doeval(gimme, NULL));
/* Restore encoding. */
PL_encoding = encoding;
+ TAINT_IF(tainted);
+
return op;
}
Inline Patch--- pp_ctl.c~ Wed Sep 26 06:23:51 2001
+++ pp_ctl.c Wed Nov 14 19:48:31 2001
@@ -2957,6 +2957,8 @@
GV *filter_child_proc = 0;
SV *filter_state = 0;
SV *filter_sub = 0;
+ OP *op;
+ bool tainted;
sv = POPs;
if (SvNIOKp(sv)) {
@@ -3063,6 +3065,8 @@
for (i = 0; i <= AvFILL(ar); i++) {
SV *dirsv = *av_fetch(ar, i, TRUE);
+ TAINT_NOT; /* must clear taintedness after previous
+ possibly tainted entry */
if (SvROK(dirsv)) {
int count;
SV *loader = dirsv;
@@ -3286,7 +3290,16 @@
PL_eval_owner = thr;
MUTEX_UNLOCK(&PL_eval_mutex);
#endif /* USE_THREADS */
- return DOCATCH(doeval(G_SCALAR, NULL));
+
+ tainted = PL_tainted;
+ if (PL_unsafe)
+ TAINT_NOT;
+
+ op = DOCATCH(doeval(G_SCALAR, NULL));
+
+ TAINT_IF(tainted);
+
+ return op;
}
PP(pp_dofile)
End of patch. |
From [Unknown Contact. See original ticket]Something like this: my $path; use lib $path; Read perlsec about how to untaint variables. Thanks, |
From @rspierWhile I agree that this is a workaround, I don't think it is a good Better would be to have perl not choke on the tainted data, of course. I have a new test case. four lines. Three files. No more big ugly :::::::::::::: -R |
From [Unknown Contact. See original ticket]Given that we want to determine dynamically where our local library support Currently we are using: #!/usr/local/bin/perl If a given command is found as a result of searching $PATH, $0 will equal a I tried using the FindBin module, but this produced the same results as the Example: #!/usr/local/bin/perl Note that the "#!/usr/local/bin/perl" forces $0 to be set to a full path. We still need to use the -U option due the use of basenames with system() Thanks in advance for any suggestions you might offer. |
From [Unknown Contact. See original ticket]With your simple test case I found the cause of the core dump in this /* Fake up a method call to import/unimport */ The method name is createad as of type SVt_PVMG because it is tainted, but Changing Perl_sv_upgrade() to not downgrade the SV if it is already in Below is the new patch for review. Thanks, Inline Patch--- sv.c~ Mon Nov 12 17:34:13 2001
+++ sv.c Thu Nov 15 12:45:21 2001
@@ -1231,7 +1231,7 @@
sv_force_normal(sv);
}
- if (SvTYPE(sv) == mt)
+ if (SvTYPE(sv) >= mt)
return TRUE;
if (mt < SVt_PVIV)
--- pp_ctl.c~ Sun Nov 4 04:35:19 2001
+++ pp_ctl.c Thu Nov 15 12:51:59 2001
@@ -3147,6 +3147,8 @@
for (i = 0; i <= AvFILL(ar); i++) {
SV *dirsv = *av_fetch(ar, i, TRUE);
+ TAINT_NOT; /* must clear taintedness after previous
+ possibly tainted entry */
if (SvROK(dirsv)) {
int count;
SV *loader = dirsv;
End of patch. |
From @gsarThis will break some kinds of code (be extra careful when changing
Sarathy |
From [Unknown Contact. See original ticket]Radu, Robert, and Richard, thanks again for all your help!! |
From @rspier
Here's the patch as suggested by Sarathy. Against latest perl-snap, all tests (still) pass under Linux. (And -R Inline Patch--- op.c.orig Thu Nov 15 11:03:47 2001
+++ op.c Thu Nov 15 11:04:49 2001
@@ -3305,7 +3305,7 @@
/* Fake up a method call to import/unimport */
meth = aver ? newSVpvn("import",6) : newSVpvn("unimport", 8);;
- sv_upgrade(meth, SVt_PVIV);
+ (void)SvUPGRADE(meth, SVt_PVIV);
(void)SvIOK_on(meth);
PERL_HASH(SvUVX(meth), SvPVX(meth), SvCUR(meth));
imop = convert(OP_ENTERSUB, OPf_STACKED|OPf_SPECIAL, |
From [Unknown Contact. See original ticket]Thanks, applied. (#13024) - ams |
From [Unknown Contact. See original ticket]Why does the following untaint a variable: if ($z =~ /(.*)/) and the following does not: $z =~ s/(.*)/$1/; Don't these do effectively the same thing? Consider the following example. When invoked where the euid != uid, it #!/usr/local/bin/perl my $evalstmt; $evalstmt = "\$var = '$0'"; $evalstmt = "\$var = '$0'"; I'm going to use the if() statement recommended by Radu, but I'm just Thanks, |
From @tamiasSubstitution does not untaint. Substitution is not documented to untaint. For example, consider $z = 'hello\nrm -rf /'; Ronald |
From @AbigailNo, consider $z = "foo\nbar". Of course, you might say, "shouldn't $z =~ s/(.*)/$1/s" untaint a variable? I don't think so. If you are doing "$z = $1", you are setting $z to something With $z =~ s///, you are replacing *part* of $z - just that in some cases $z =~ s/(\w+) (\w+)/$1 $2/ untainted $z just because $z happened to consist of two words separated Abigail |
From [Unknown Contact. See original ticket]Thank you for setting me straight. Also please forgive my ignorance with Thanks again for your help and I hope everyone has a nice weekend. Dave |
From @vanstynNo; the latter is effectively the same as: Hugo |
@cwest - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#7273 (status was 'resolved')
Searchable as RT7273$
The text was updated successfully, but these errors were encountered: