[29448] in Perl-Users-Digest
Perl-Users Digest, Issue: 692 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 27 14:09:44 2007
Date: Fri, 27 Jul 2007 11:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 27 Jul 2007 Volume: 11 Number: 692
Today's topics:
Re: @arts <v_r@spamless.and.happy>
Re: @arts <michaellhartsough@sbcglobal.net>
Block of statements after "open" and before "die" <bew_ba@gmx.net>
Re: Block of statements after "open" and before "die" <peter@makholm.net>
Re: Block of statements after "open" and before "die" xhoster@gmail.com
Re: Block of statements after "open" and before "die" <1usa@llenroc.ude.invalid>
Re: I am giving up perl because of assholes on clpm -- <redgrittybrick@spamweary.foo>
Re: Math <blb8@po.cwru.edu>
Re: Math <hjp-usenet2@hjp.at>
Re: Objects/Structures in Perl <olson_ord@yahoo.it>
Re: Perl with DBI <hjp-usenet2@hjp.at>
Re: Perl with DBI <hjp-usenet2@hjp.at>
Re: Perl with DBI <sbryce@scottbryce.com>
Re: pid from startet process (Douglas Wells)
Re: Problem installing DBI <joliver@john-oliver.net>
Re: Using backticks in forked child <kingskippus@gmail.com>
Re: Version for Script? <scobloke2@infotop.co.uk>
Re: Version for Script? <glex_no-spam@qwest-spam-no.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 27 Jul 2007 09:02:57 -0700
From: "V.Ronans" <v_r@spamless.and.happy>
Subject: Re: @arts
Message-Id: <FeednZoO3uupijfbnZ2dnUVZ_hGdnZ2d@wavecable.com>
Tad McClellan wrote:
> Mike Hartsough <michaellhartsough@sbcglobal.net> wrote:
>> Tad McClellan wrote:
>>> Mike Hartsough <michaellhartsough@sbcglobal.net> wrote:
>>>
>>>
>>>> I saw no proof offered by Michele Dondi nor Tad McClellan, who
>>>> decided to join in rather than point out the Posting Guidelines,
>>>
>>>
>>> Specifically because the Jsut troll deserves no better.
>>>
>>> (ie. this poster has a history here)
>>
>> So you're saying you have the right to accuse anyone of being this
>> "Jsut troll" without any evidence to prove it?
>
>
> No.
>
> And that did not happen in this thread as it slipped up yet again
> and revealed itself.
How So? Where is your proof that I or anyone else is your troll?
------------------------------
Date: Fri, 27 Jul 2007 09:49:03 -0700
From: "Mike Hartsough" <michaellhartsough@sbcglobal.net>
Subject: Re: @arts
Message-Id: <nApqi.14$AC7.2@newssvr19.news.prodigy.net>
Michele Dondi wrote:
> On Fri, 27 Jul 2007 00:54:10 GMT, "Mike Hartsough"
> <michaellhartsough@sbcglobal.net> wrote:
>
> > You were asked nicely by a two people, so where was the problem?
>
> If you were asked nicely by "a two people" (on USENET!!!) to stick a
> pen up your ass, would you do it?
In what way is "stick a pen up your ass" any near the same as "please
properly attribute your quotes" ? The latter is also in the "Posting
Guidelines", so why do you keep looking for ways around that, instead of
just admitting you were wrong? Or do you not consider the guidelines to
be important enough, nor consideration for generally accepted
UseNet/forum "netiquette" ?
> > > Well, you know, I hardly ever mention the posting guidelines nor
> > > direct people towards them: you can check by searching my past
> > > posts.
> >
> > I did, and you have on many occasions directed people to them:
> >
> > http://groups.google.com/groups?as_q=&num=100&hl=en&as_epq=posting+guidelines&as_uauthors=Michele+Dondi
>
> Well, for one thing the search you're suggesting turned out 16, I say
> *16* results. If you search
>
> http://groups.google.com/groups?q=author%3AMichele+author%3ADondi+group%3Acomp.lang.perl.misc&num=100
>
> instead, you'll find 2250, I say *2250*.
So you just proved my point here even more. and you did a different
search altogether. Mine is measuring how many times you mentioned the
guidelines. You also missed the point the it's not just you, but other
regulars mention them almost religiously.
> Do those sixteen qualify as "many"?!?
I actually get 24 (what is it with google groups these days only
returning partial results?), but either way, your original assertion,
that you "hardly ever mention" or "direct people" to the guidelines is
wrong, even if you don't do it as often as others.
Regards
Mike
------------------------------
Date: Fri, 27 Jul 2007 09:12:19 -0700
From: bernd <bew_ba@gmx.net>
Subject: Block of statements after "open" and before "die"
Message-Id: <1185552739.549421.134870@l70g2000hse.googlegroups.com>
Hello folks,
I wondering whether it is possible to execute more statements than the
"traditional" die after the invocation of open in a perl script:
Instead of:
open (FH, ">testfile") or die "Cannot open testfile" ;
I want to do a little bit more. My idea is deployment of a "do"-block
open (FH, ">testfile") or do { # some other stuff, e.g. sending a mail
message; die "Cannot open testfile" }
my @include ;
This does not seem to work. In my case the statement declaring an
array immediately after the do block is refused by the compiler with
the message:
"Global symbol @include requires a package name..."
Apart from the $SIG(__DIE__)-stuff, which, from my point of view is
not that obvious, do I have any other possibility?
Cheers
Bernd
------------------------------
Date: Fri, 27 Jul 2007 16:24:45 +0000
From: Peter Makholm <peter@makholm.net>
Subject: Re: Block of statements after "open" and before "die"
Message-Id: <87fy39lsqa.fsf@hacking.dk>
bernd <bew_ba@gmx.net> writes:
> I want to do a little bit more. My idea is deployment of a "do"-block
>
> open (FH, ">testfile") or do { # some other stuff, e.g. sending a mail
> message; die "Cannot open testfile" }
>
> my @include ;
You're missing a ; after the 'do { ... }'. do BLOCK isn't a part of
the syntax like if and fo. It is just like a function taking a code
block as argument like sort and map.
//Makholm
------------------------------
Date: 27 Jul 2007 16:26:09 GMT
From: xhoster@gmail.com
Subject: Re: Block of statements after "open" and before "die"
Message-Id: <20070727122611.454$5M@newsreader.com>
bernd <bew_ba@gmx.net> wrote:
> Hello folks,
>
> I wondering whether it is possible to execute more statements than the
> "traditional" die after the invocation of open in a perl script:
>
> Instead of:
>
> open (FH, ">testfile") or die "Cannot open testfile" ;
>
> I want to do a little bit more. My idea is deployment of a "do"-block
>
> open (FH, ">testfile") or do { # some other stuff, e.g. sending a mail
> message; die "Cannot open testfile" }
>
> my @include ;
You need a ";" after your do block.
> This does not seem to work. In my case the statement declaring an
> array immediately after the do block is refused by the compiler with
> the message:
>
> "Global symbol @include requires a package name..."
Before the global symbol error, I get another error message:
syntax error at -e line 1, near "} my "
Don't you get that error, too? It generally doesn't make sense to worry
about declaration errors when earlier syntax errors are also present.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 27 Jul 2007 17:32:01 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Block of statements after "open" and before "die"
Message-Id: <Xns997A89B0EEB0Casu1cornelledu@127.0.0.1>
bernd <bew_ba@gmx.net> wrote in news:1185552739.549421.134870
@l70g2000hse.googlegroups.com:
> Hello folks,
>
> I wondering whether it is possible to execute more statements than the
> "traditional" die after the invocation of open in a perl script:
>
> Instead of:
>
> open (FH, ">testfile") or die "Cannot open testfile" ;
>
> I want to do a little bit more. My idea is deployment of a "do"-block
>
> open (FH, ">testfile") or do { # some other stuff, e.g. sending a mail
> message; die "Cannot open testfile" }
Peter and Xho have pointed out the syntax error. I will suggest that
putting a lot of stuff after the 'or' is not good style. Just like
chaining a whole bunch of statements with 'and's and 'or's. You can a
simple unless to achieve the same or call a subroutine:
my $fh;
unless ( open $fh, '>', 'testfile' ) {
...
}
Or:
open my $fh, '>', 'testfile' or handle_file_open_error( 'testfile' );
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Fri, 27 Jul 2007 17:12:48 +0100
From: RedGrittyBrick <redgrittybrick@spamweary.foo>
Subject: Re: I am giving up perl because of assholes on clpm -- switching to Python
Message-Id: <46aa1986$0$31715$db0fefd9@news.zen.co.uk>
Paul Rubin wrote:
> M brad <byte8bits@gmail.com> writes:
>
>> Out of the pan and into the fire. :) Welcome to the world of Ph.D's
>> in Computer Science. You think the Perl guys have attitude, just
>> wait and see what you're in for over here. I think you'll find
>> attitudes in any programming language... just different types. May
>> God have mercy on your soul! You'll be making a similar
>> announcement in a few weeks when you switch to Ruby :) The cold,
>> cruel theoretical, lofty Python will mercilessly crush you :)
>
>
> Come over to comp.lang.functional sometime. I thought I was hardcore
> but my brain is not big enough for that newsgroup.
http://www.catb.org/~esr/faqs/smart-questions.html#not_losing
In most of the technical computer newsgroups which I frequent, there is
a handful of knowledgeable and helpful but irritable regulars, and often
one or two saints who contribute usefully, ignore rudeness and almost
never post off topic.
I find it best to treasure the saints, tolerate the irritable and ignore
the whiners.
YMMV.
--
RGB
No saint.
------------------------------
Date: Fri, 27 Jul 2007 15:47:57 +0000 (UTC)
From: Brian Blackmore <blb8@po.cwru.edu>
Subject: Re: Math
Message-Id: <f8d43c$5ed$1@gnus01.u.washington.edu>
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> [A complimentary Cc of this posting was sent to
> Brian Blackmore
> <blb8@po.cwru.edu>], who wrote in article <f82pte$kl3$1@gnus01.u.washington.edu>:
> > > For some unfathomable reasons, Perl uses non-invertible transformations
> > > between strings and numbers. So if your handling of numbers involves
> > > converting them to strings, then back, the precision will be lost.
> > Yes, but I would question which programming languages don't suffer
> > from this behavior?
> What other programming languages with multi-representation numbers do
> you know?
Yeah, I have to apologize here because I've conflated a couple of
ideas and caused a minor communication problem. Certainly the 1/3
issue is a matter of representation, whence a different issue, but I
brought that in from the other part of the thread. I think I've
been looking for a specific example to the first statement way up
above here, about losing precision during conversion. Is what you
had in mind something like this:
#!/usr/bin/perl
$a=42.1; for (1..30) { $a+=0.1 }
$b="$a"; print "a=",$a," b=",$b,"\n";
$a==$b ? print "Equal\n" : print "Not equal\n" ;
> > As is mentioned by perlnumber, converting from
> > floating point to string is performed by the C compiler,
> Nope, by C RT libraries. And the for these libraries, they do it
> following instructions from perl.
I would like to know for future reference if this is in the manuals
or if I misinterpreted what's in perlnumber. Also, are these
instructions discussed anywhere, or just in the source? I'd like to
know exactly what's happening, so I can look at the sources, but it
might be nice to have this type of example in perlnumber.
> > whence Perl is at the mercy of the system on which it was compiled.
> And this the CHOICE made by perl. It could have done the conversion
> itself.
Is it a choice of what parameters to pass to CRTL that is causing
the fault, or is it the choice to use the CRTL period? If it's a
parameter issue, why haven't the parameters been changed?
> > Moreover, I must admit a bit of childish moronicity here in claiming
> > that I know of no language whatsoever that stores floats with
> > infinite precision, whence string conversion is always faulty.
> I do not follow your usage of "whence", so cannot comment.
Sorry, I conflated in the 1/3 example here.
Thanks all for the patience, and I hope we're not too far off topic,
but I just want to make sure I understand what actually is
unfathomable here and why, so I don't fall prey to these problems in
the future.
--
Brian Blackmore
blb8 at po dot cwru dot edu
------------------------------
Date: Fri, 27 Jul 2007 18:57:40 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Math
Message-Id: <slrnfak904.k73.hjp-usenet2@zeno.hjp.at>
On 2007-07-27 12:26, José Luis Pérez Diez <jluis@escomposlinux.org> wrote:
> In article <slrnfahqf9.i1m.hjp-usenet2@zeno.hjp.at>, Peter J. Holzer
> wrote:
>> Nope. Converting a binary number of a given precision to decimal and
>> back to binary is always possible without loss[0]. The problem seems to
>> be that perl uses only 15 decimal digits, while it would need 16 to
>> cover the 53 bits of mantissa (I think 16 should be enough, but I
>> haven't considered all cases - maybe there are some where 17 are
>> required).
>>
> perl -Mbignum=a,100 -e 'my $numero=0; for (0..53) {$numero+= 1/2**$_}
> ;$numero =~ s/0*$//g;print length($numero)."\n$numero\n";'
> 55
> 1.99999999999999988897769753748434595763683319091796875
I'm not quite sure what you are trying to demonstrate here. That number
is not exactly representable in an IEEE-64bit-FP number (the mantissa is
one bit too long, afaics).
The nearest two numbers are
1.9999999999999997779553950749686919152736663818359375 and 2.0
1.9999999999999997779553950749686919152736663818359375 is adequately
represented by 1.9999999999999998, which indeed uses 17 digits in
decimal. So you have demonstrated that at least 17 decimal digits are
needed to represent 53 bits of mantissa. That answers my question -
thanks; but I would have preferred a more direct answer.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Fri, 27 Jul 2007 17:52:32 -0000
From: "O. Olson" <olson_ord@yahoo.it>
Subject: Re: Objects/Structures in Perl
Message-Id: <1185558752.760041.195290@57g2000hsv.googlegroups.com>
Dear Jens,
I this is exactly what I wanted. I searched again on Google - but I
could not get the method you suggest anywhere on the net. I think I
have understood it overall - but I have a few questions.
On Jul 27, 2:19 am, j...@toerring.de (Jens Thoms Toerring) wrote:
> I can't answer this queston - my question is how you did get that
> output at all since (for several reasons) your above code isn't
> valid Perl?
>
I am running this using ActiveState Perl 5.8.7.815 under Windows XP.
I tried rerunning my exact same code that I posted again - and it does
give the same/similar output to what I have posted above.
My Questions:
> package MyTime;
>
Can this package be declared in a separate file - I tried it - but it
would not work. I put this in a file called "MyTime.pl" and in the
original source file put "use main::MyTime;". This does not work.
> sub new {
> my $inv = shift;
> my $class = ref( $inv ) || $inv;
> die "Too many arguments\n" unless @_ <=3;
> my $self;
> if ( @_ == 0 ) { # no arguments
> my @time = localtime( );
> $self = { hour => $time[ 2 ],
> minute => $time[ 1 ],
> second => $time[ 0 ] };
> } else {
> $self = { hour => $_[ 0 ],
> minute => $_[ 1 ] || 0,
> second => $_[ 2 ] || 0 };
> }
> return bless $self, $class;
>
> }
>
I think I did not understand some of the aspects of this new()
function - though I liked the clever way you created a new hash
everytime a new object of the class is required. Keith above mentioned
that I should do this - but he did not elaborate that way you did it.
1. I think from the documentation that "shift" would decrease the size
of the array @_ by 1. So shouldn't that at the top be @_ <=2;
2. I think I did not understand what the second line does:
my $class = ref( $inv ) || $inv;
3. Is $time sort of an implicit variable. I looked at the "localtime"
function at http://perldoc.perl.org/functions/localtime.html and I
could not find any mention of it.
4. Finally I have no idea about:
return bless $self, $class;
I looked at http://perldoc.perl.org/functions/bless.html regarding
bless - but I did not understand how $class would refer to the current
package.
>
> 1;
> ------8<-------------------------------------------------------
>
I would also like to know if every file in Perl should end with a 1; -
I did not know this before - but only learnt about it when you used
it.
> Regards, Jens
Thanks a lot for your code :) I think that's exactly what I wanted.
vielen Danke,
O.O.
------------------------------
Date: Fri, 27 Jul 2007 19:32:21 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl with DBI
Message-Id: <slrnfakb15.k73.hjp-usenet2@zeno.hjp.at>
On 2007-07-27 06:19, Jason <jwcarlton@gmail.com> wrote:
> The program seems to not like the single-quotes. I created a table
> from phpMyAdmin and copied the exact code in to the program, and that
> worked fine. But instead of single-quotes, it used back-ticks.
>
> So, instead of:
>
> $dbh->do("CREATE TABLE 'Test 3' ('date' VARCHAR(14)...
>
> Using this worked:
>
> $dbh->do("CREATE TABLE `Test 3`(`date` VARCHAR(14)...
>
> Why?
Because in SQL single quotes delimit strings. Table and column names are
not strings, so they must not be enclosed in single quotes. They are
identifiers and should normally be used without quotes. It is possible
to use tables and columns with characters which aren't allowed in
identifiers (such as the space in "Test 3") but that isn't portable
between databases (on MySQL you need to use backticks, on Oracle double
quotes) so you should avoid it:
$dbh->do("CREATE TABLE Test3 (date VARCHAR(14)...
(the use of "date" as a column name may also be unwise - that's a
keyword in some SQL dialects. And you may want to use the datetime or
timestamp type here instead of VARCHAR(14))
> I couldn't tell you. None of the tutorials I read commented on
> this.
Probably none of the tutorials advised you to use quotes on table and
column names at all.
> But this leads me to my next question. I want `Test 3` to be a
> variable, but using
>
> $dbh->do("CREATE TABLE param('var') (`date` VARCHAR(14)...
>
> is giving that same generic error as above. I tried it both with and
> without the quotes, and tried using a variable instead ($var =
> param('var');), but still received the same error.
You mean:
$var = param('var');
$dbh->do("CREATE TABLE $var (`date` VARCHAR(14)...
That should work if param('var') (which I assume is calling the CGI
method) returns a suitable table name.
But this is very dangerous unless you tightly restrict the users who can
invoke your CGI script. A user could invoke almost any SQL command this
way (read up on "SQL injection").
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Fri, 27 Jul 2007 19:32:49 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl with DBI
Message-Id: <slrnfakb21.k73.hjp-usenet2@zeno.hjp.at>
On 2007-07-27 14:35, Scott Bryce <sbryce@scottbryce.com> wrote:
> Jason wrote:
>> But this leads me to my next question. I want `Test 3` to be a
>> variable, but using
>>
>> $dbh->do("CREATE TABLE param('var') (`date` VARCHAR(14)...
> -------------------------^^^^^^^^^^^^
>
>> is giving that same generic error as above.
>
> ITYM $param('var').
What is that supposed to mean?
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Fri, 27 Jul 2007 11:41:16 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Perl with DBI
Message-Id: <io2dndXxAqOkszfbnZ2dnUVZ_rWtnZ2d@comcast.com>
Scott Bryce wrote:
> Jason wrote:
>
>> But this leads me to my next question. I want `Test 3` to be a
>> variable, but using
>>
>> $dbh->do("CREATE TABLE param('var') (`date` VARCHAR(14)...
>
> -------------------------^^^^^^^^^^^^
>
>> is giving that same generic error as above.
>
>
> ITYM $param('var').
No, I don't think that is what you meant. (What was I thinking? Was I
thinking at all?)
param('var') is a function. As such it is not interpolated into the string.
------------------------------
Date: Fri, 27 Jul 2007 13:19:40 -0400 (EDT)
From: see@signature.invalid (Douglas Wells)
Subject: Re: pid from startet process
Message-Id: <f8d9fc$ii$1@flame.contek.com>
In article <slrnfajk31.jjr.hjp-usenet2@zeno.hjp.at>, "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2007-07-26 22:57, Douglas Wells <see@signature.invalid> wrote:
> > In article <slrnfahnt5.i1m.hjp-usenet2@zeno.hjp.at>,
> > "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> >> PIDs are guessable on the majority of unix systems (the only exceptions
> >> I know are some BSD variants) - so this is something the average unix
> >> programmer expects.
> >
> > Yes, elsewhere in this thread, I acknowledged that I made a wrong
> > declaration about "most" POSIX-like system: Many of them do
> > generate new candidates for PIDs by incrementing a counter. I
> > have not, however, yielded on the claim of a security threat posed
> > by this algorithm. Instead, I supplied a scenario, based on
> > historical security incidents, that posed a threat in the presence
> > of this algorithm.
>
> Yes. If you had yielded that claim I wouldn't have had any reason to
> answer. But since you haven't, I had to object.
And I still don't. You are describing a situation where an
application programmer makes an erroneous assumption, and that
assumption results in a security problem.
> The pid has traditionally always been a simple wrap-around counter. Any
> unix programmer should know this.
That depends on your definition of "traditionally." Yes, the
standard code base from AT&T did this, and many of the derivative
systems also did this. However, that is irrelevant, as it was not
guaranteed by either the system specification or a published
standard. (And, I know of systems at least as far back as 1982 that
used non-sequential PIDs.). A programmer may know that this is the
way that things often work, but he/she shouldn't depend on something
that isn't *documented* as a permanent characteristic of the
system. And, if you are targeting a portable platform, such as
POSIX, you need to be aware of possible differences across
implementations of that platform.
> Using it in a context where a random
> number (much less a cryptographically strong random number) is required
> is just using the wrong tool for the job. Such an error may lead to a
> security problem, but that's the fault of the programmer, not the tool.
> (In your scenario, the real error is probably not using O_EXCL, btw, not
> using the pid, but that depends on the intended use).
Yes, *one* underlying error was not using O_EXCL -- as I implied
by my reference to O_EXCL in that post.
As decoded in a parallel sub-thread, it would appear that a real
problem underlying your concern was a dependence on a time delay
before reuse of PIDs. That characteristic, of course, is not
currently a guarantee of the POSIX/UNIX standard, and I can find
no instances of any system documentation promising that.
The question we have before us seems to be how to attribute the
blame of being a security flaw. Consider the case of using an
uninitialized variable in a program. It can be the case that that
variable happens to inherit a value that causes the the program
to behave reasonably. As time elapses that accidental value can
change for any number of reasons: the level of optimization changes,
the compiler changes, other code in the program changes and happens
to leave a different value in that location, or the program is
moved to a different platform.
When that program later misbehaves, leaving a loss of data (and a
security problem using your definition), one shouldn't point to
the new compiler or the different platform as the security problem.
The security flaw is the improper coding in the original program.
In the case of the example that you provide in a parallel sub-thread,
the basic security flaw is clearly at the hands of the designers
of the maildir format (assuming your description is correct, which
I don't doubt). They made an assumption that wasn't true across
the targeted platforms.
Security experts, for both computers and otherwise, note that
vulnerability is the product of the existence of security
vulnerabilities and the presence of security threats. In this
case, the introduction of a system with randomized PIDs increased
the level of security threat, but that doesn't mean that the use
of randomized PIDs is itself a security threat, which is an
implication, but not explicit claim, of your earlier message to
which I was reacting.
So, with that said, let me react to the rest of your message:
> Yes. A linearly incrementing pid has some minimum time between the start
> time of two processes with the same pid. Typically, about 30000 forks
> are needed before the same pid can be reused.
>
> A programmer which knows this may assume that the start time of the
> process with suitably high resolution (for example 1 millisecond - 1
> second is already too grainy given current computer speeds) together
> with the pid is always unique: The system would need to be able to fork
> 30000 processes within 1 ms, which is far beyond the capabilities of
> current systems and will stay impossible for some time.
Right, and that programmer is creating a bug by depending on a
characteristic that is not guaranteed by any spec.
> I know a number of applications which didn't work correctly on BSD
> systems after randomized pids were introduced. The results were usually
> lost data or data leaked to a different user, so that was at least
> potentially security-critical.
Agreed, and the security problem was in the application. The
introduction of the use of the "BSD" system (I'm presuming that
this was likely OpenBSD) increased the security threat by altering
more characteristics of the platform.
> Personally, I think it's a good thing that these applications were
> broken, because it alerted the maintainers that the assumption
> "timestamp + pid is unique" was faulty way before it became faulty on
> systems on which it may have been possible to systematically exploit the
> bug (IIRC all these applications used a one-second timestamp which is
> now getting too short).
>
> I'm not saying that random pids are bad /per se/. But the average unix
> programmer probably doesn't know that they exist so he cannot consider
> their consequences.
OK, and the way to deal with that is to teach those programmers
how to write portable applications by not depending on accidental
characteristics.
> (As an aside: Is the randomness of the pids on BSD systems
> cryptographically strong? If not, a programmer might assume they are and
> make the same error as a programmer who thinks that linearly incremented
> pids are "non-predictable". If they are, how about other systems with
> random pids?)
I don't know about those particular systems, but often such algorithms
are pluggable and can be replaced depending upon the security
requirements of the deployed environment. Given that the rate of
production of PIDs is slower, and the visibility of PIDs is lower
than communication data, the tolerable level of strength would be
lower.
> hp
- dmw
--
. Douglas Wells . Connection Technologies .
. Internet: -sp9804- -at - contek.com- .
------------------------------
Date: 27 Jul 2007 17:19:48 GMT
From: John Oliver <joliver@john-oliver.net>
Subject: Re: Problem installing DBI
Message-Id: <slrnfaka9k.oq9.joliver@ns.sdsitehosting.net>
On Thu, 26 Jul 2007 22:08:46 -0700, Mark Pryor wrote:
> On Thu, 26 Jul 2007 18:02:04 +0000, John Oliver wrote:
>
>> On Wed, 25 Jul 2007 17:38:25 -0700, Mark Pryor wrote:
>>> On Wed, 25 Jul 2007 23:31:25 +0000, John Oliver wrote:
>>>
>>>> On a CentOS 5 system:
>>>>
>>>> [root@rt-2 rt-3.6.4]# perl -MCPAN -e 'install DBI'
>>>> CPAN: File::HomeDir loaded ok (v0.65)
>>>> Sorry, we have to rerun the configuration dialog for CPAN.pm due to
>>>> the following indispensable but missing parameters:
>>>
>>> Stop there. Why install DBI when this package is already a Core RPM,
>>> called perl-DBI? Granted its not the latest, 1.52, but you don't need to
>>> install from scratch.
>>>
>>> #rpm -qa | grep DBI
>>>
>>> The CentOS 5 has a very complete Perl environment, especially if you have
>>> all the LAMP packages. To verify this do
>>>
>>> #yum groupinfo "MySQL Database"
>>> #yum groupinfo "Web Server"
>>>
>>> Using Perl in CentOS is alot more fun and painless if you treat RPM and
>>> YUM as your friends.
>>
>> Yes, I'm aware of all that.
>>
>> I'm trying to install RequestTracker. It's a frickin' nightmare. Since
>> RT is in the Fedora Extras, I installed a host with FC7 and installed RT
>> from yum. I can't get it to work. On the RT mailing list, they keep
>> saying "We don't know why the RPM doesn't work, you have to install from
>> source". So that's what I'm trying to do... but RT's dependency checker
>> wants DBI installed via CPAN. There isn't much point with my arguing
>> with why they want to do certain things certain ways... I'm just trying
>> to do everything their way so hopefully at some point I can wind up with
>> a working RT installation.
>
> C5 is based on FC6 sources. Might this be a better bet?
> http://fedora.kanarip.com/fedora/extras/6/i386/rt3-3.6.3-1.fc6.noarch.rpm
Yes, yes, yes...
I have a FC7 installation with RT installed from Extras. It does not
work. I am trying to install from source since the people on the RT
list insist that that's the only way it will work. If you know how to
make the RPM install of RT work, I'd be more than happy to do it that
way. Otherwise, could I just find out why DBI won't install from CPAN?
Please?
--
* John Oliver http://www.john-oliver.net/ *
------------------------------
Date: Fri, 27 Jul 2007 08:44:01 -0700
From: TonyV <kingskippus@gmail.com>
Subject: Re: Using backticks in forked child
Message-Id: <1185551041.371152.236280@57g2000hsv.googlegroups.com>
On Jul 26, 7:38 pm, deoqu...@yahoo.com wrote:
> Hello all, I have a a need to use backticks in a forked child while
> running many simultaneous children (on Windows).
I've run into this too, forked processes working fine until you throw
a system call using backticks in the mix, then they die, and I don't
know how to correct it.
Anyone else know what's happening?
------------------------------
Date: Fri, 27 Jul 2007 17:46:20 +0100
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: Version for Script?
Message-Id: <46aa2162$0$24761$da0feed9@news.zen.co.uk>
T wrote:
> Greetings:
>
> At the beginning of all my Perl scripts I do:
>
> #!/usr/local/bin/perl -w
> # $Id$
>
> The $Id$ will expand out in RCS/CVS to a version. My question is there
> a way for me to get this in perl? It's in a comment line so will be
> ignore by perl, but wondering if there's another way around this or
> should I just create a $version variable and control the version that
> way?
>
> Thanks for any help in advance!
>
> T
>
#!perl
#
# $Author$
# $Date$
# $Header$
# $Id$
# $Locker$
# $Log$
# $Name$
# $Revision$
# $Source$
# $State$
#
use strict;
use warnings;
my $identifier = '$Id$';
print "Id : $identifier\n";
my $Revision = ''; // keep interpolater happy
my $nothing = ''; // ditto
print "Revision $Revision$nothing\n";
RCS/CVS don't care if the $Id$ is not in a comment, and will update all
occurrences of such keyword strings wherever they appear.
------------------------------
Date: Fri, 27 Jul 2007 12:16:45 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Version for Script?
Message-Id: <46aa287e$0$3569$815e3792@news.qwest.net>
Ian Wilson wrote:
> T wrote:
>> Greetings:
>>
>> At the beginning of all my Perl scripts I do:
>>
>> #!/usr/local/bin/perl -w
>> # $Id$
>>
>> The $Id$ will expand out in RCS/CVS to a version. My question is there
>> a way for me to get this in perl? [...]
> my $identifier = '$Id$';
> print "Id : $identifier\n";
> my $Revision = ''; // keep interpolater happy
> my $nothing = ''; // ditto
> print "Revision $Revision$nothing\n";
>
> RCS/CVS don't care if the $Id$ is not in a comment, and will update all
> occurrences of such keyword strings wherever they appear.
Or a little nicer, set your $VERSION to the Revision used by CVS.
# $Revision: $
use vars qw($VERSION);
$VERSION = sprintf "%d.%03d", q$Revision: $ =~ /(\d+)/g;
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 692
**************************************
