Re: [opensuse] Need some help with a script


----- Original Message ----- From: "Randall R Schulz" <rschulz@xxxxxxxxx>
To: <opensuse@xxxxxxxxxxxx>
Sent: Friday, February 06, 2009 10:48 AM
Subject: Re: [opensuse] Need some help with a script


On Friday February 6 2009, nordi wrote:
Randall R Schulz wrote:
> what is the danger?

Apart from the obvious security aspects you also risk having an
executable in ./ that will modify the behavior of another program you
are running. ...

These endless, arcane and tortured hypothetical scenarios beggar belief.

hahahha wow, that's exactly what every non-programmer, non-mechanic
non-electrical engineer, non-db-admin, non-accountant, non-doctor,
non-anything-remotely-techy person says about every techy topic once
you start to get even slightly detailed.
Things don't work by accident.
And they don't work because engineers "feel" that this or that isn't "likely".
Things only work by dint of lot's of people all thinking about exactly those
"tortured hypothetical scenarios" because, duh, they aren't hypothetical at all.
They ALL happen.
It doesn't matter if a thing is likely or unlikely.
It only matters if it's possible or not possible.

The world, at least todays world, only even works at all because
enough of the people that make things work, try to always
think robustly. Enough so that in fact lots of sloppy thinkers
can actually get away with a lot. If a given system involves 4
parts, and 3 of them were designed robustly, the 4th guy can actually get
away with turning out some crap. The system as a whole will work
well enough because the _other_ guy didn't think in terms of
likely or unlikely. He didn't think in terms of "this would be some
really tortured hypothetical scenario so why worry about it?"

In fact, a fair bit of the time as long as at least one part
of a system is solid and does the sane thing most of the time,
sometimes that's enough to make the whole system "good enough".
So a lot of people get into positions where they are turning
out crap and don't even know it.
But do you actually want to be that guy? Knowingly?
Further, it's irresponsible to go further and actually
advise to others that they don't have to be careful either
just because you've discovered that you can get away
with it.

The question isn't "What will happn?"
It's "What have I allowed?"
And "Have I set things up so that WHEN they fall over,
they fall in the least harmful direction?"

Baby talk programming example.
You are counting in a loop from 1 to 10, in incriments of 1.
It's a dead simple loop, can't possibly screw up in any weird way.
Never the less at the exit point of your loop, you don't check
for n=10, you check for n>9 or n>=10. It doesn't matter in the
slightest how simple the loop is or that it will never ever
mistakenly miss a beat and exceed 10 and thus spin away forever
counting up to infinity.
It doesn't matter, you still ALWAYS test for greater
than or equal to 10, not just equal to 10. Because that is the
robust way and it costs you little or nothing to do it the
solid way vs the risky way.
If it's not OK for your program to count from 11 to infinity, then
you don't allow it.
It's not a matter of thinking up tortured hypothetical scenarios.
You don't have to say "What if n were 12? Ok I accounted for 12.
Now, what if n were... 327? OK dealt with 327. Now, what if n
were... " No you just think of one thing, is n less than 10 or
not? I don't care what it is outside that range.

Dot in path is like that. The question isn't who might place
a file in a place where you will end up executing it,
nor is the question what might they put there.
The question is can anyone do anything like that.
Without dot in path, they can't.

You realise of course that "they" is just as much "you"
as anyone else. I've watched so many people get tripped
by the simple case of "test". They forget that test is a
system binary, usually not actually called because usually
the shell builtin gets used, but, it still exists as a binary
for a reason and sometimes gets used. So they're working on some
script and of course they name it, or it's sample data, "test",
which ends up screwing up all manner of far reaching things
because that's such a basic command peppered throughout
so many scripts in the system. It's like replacing the letter "e"
with something else throughout. what would that screw up?
I don't know exactly either but I know it's a lot.
And I don't have to actually try it to know it. I don't
have to actually have the "dead baby" to point at explicitly.
In fact, what I said about everyone else being good so
one guy can get away with being a walking disaster would
probably kick in here.
Everyone _else_ who writes a script that's part of the
system, generally ensures somehow that the various commands
used in the script actually come from some known place.
They set an overriding PATH at the top, they explicitly
use the shell builtin command, they explicitly call the
external commands by full absolute path, sometimes they
go so far as to supply their own commands with the script,
or impliment the equivalents of some commands entirely
within the script itself, _something_. They only suffer
all that inconvenience becaause they need to, because
untill they did, it kept blowing up. Not because that's
how they wanted to spend all those nights & weekends.
Precisely because everyone else considers those
"tortured hypthetical scenarios" is why you could actually
probably get away with not considering them yourself and
most parts of the system would still work. I suppose
that you interpret this as supporting your argument?
That you don't have to be careful because everyone
around you is being careful for you?

Back to the simple programming example.
2 years passes and that dead simple loop has grown into a larger
more complicated routine that does a bit of jumping around, and,
you are no longer the only programmer futzing with it either.
Other people, of questionable skill or powers of observation,
have been and will continue to be modifying it.
Sooner or later that counter is going to get screwed up and n is
going to jump by more than 1 in a single iteration and it's going
to skip right over that magic threshhold value you were looking for.
But, no problem, it should have been impossible to ever reach 11,
but by testing for >= you don't care _what_ value n jumps to, you
still handle it and your program, which might be part of an aircraft
autopilot, or a medical monitor or dosimeter, or a parking meter timer,
or a web site billing calculator, or _anything_, works.
It's not a tortured hypothetical scenario, it's exactly what
happens all day every day a zillion times a second in life, in every
clock radio and air-bag deployment system and not a few doorknobs.

Now maybe you want to say this last scenario doesn't apply, because
you don't now and will never have other users on your system?
Much flawed logic there. But the two biggest are:
1 - Every time you run any binary or script that you didn't personally
write, you are essentially letting other users on your system.
2 - You didn't just do something on your own system but suggested
in a public place frequented by new users who don't know better,
they they do the same. To use the programming analogy again,
you told other programmers to write poor code, some of whom will
use this advice in places where it will cause a disaster.
Even if the disaster is just that they show me an example of their
code and I don't hire them because of it. That's a pretty big
disaster for at least somebody. And I sure wouldn't let any fan of
dot-in-path near my boxes at least until I cured them of that and
established are they really that much of an idiot or did they merely
fall prey to some bad advice and haven't yet aquired the hard knocks
to correct that particular lack of thinking things through.

Lastly, "every other dir on the system has the same problem"
is absolutely cotton-headed thinking. Without dot-in-path,
path is a defined and fixed set of a very few directories,
all of which have basic permissions such that users can not
write new files there, nor alter any files that are already
there. "." on the other hand includes every directory on the
whole system, including ones not only your current user
has permission to write to, but ones any user even user "nobody"
used by the web server, has permission to write to.
What, you never ever once cd'd to /tmp and then ran a command
like ls or cat ir vi etc... without first making sure that
there wasn't a file in /tmp that had the same name?
Even if you were that perfect, no one else is, and even if
everyone else was, it's still absolutely inexcusably poor
design to rely on that.

This discussion has of course outgrown "dot in path".
Like I tried to express before with the "doesn't kill babies"
quip, dot in path is just one item.
No more harmful than any other, but no less.
What I'm talking about is the thinking that leads to "dot in path"
also leads to a zillion other similar bad ideas, and
cumulatively that is very bad.

--
Brian K. White brian@xxxxxxxxx http://profile.to/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages

  • =?ISO-8859-1?Q?New_System_Command_Script_Facility?=
    ... I'm currently finished writing a new replacement command script processor ... (at least that RACF thinks so, and better support for non-RACF sites). ... The IF-type commands now have ELSE processing ... non-scroll highlighted console message and BEEP until a specific JOB or TASK ...
    (bit.listserv.ibm-main)
  • Re: Command Line Interface
    ... >> should accept system commands only for an administrator. ... >> how should I supress the bash shell and launch my custom CLI ... > The script could run in a restricted shell and offer a menu of ... account, and either 1) change account password, 2) ...
    (comp.os.linux.misc)
  • Net::Telnet and SMTP
    ... I'm trying to send a sequence of commands and then log both the ... I've included the script and a sample text file (that feeds the scripts ... sub processfile { ... #Try a short delay between sending command and reading output ...
    (comp.lang.perl.misc)
  • Re: Creative ways to time scripts?
    ... commands, but commands that also don't do anything. ... The script could be for either. ... Either in a single program or systemwide (in Windows of ...
    (microsoft.public.scripting.vbscript)
  • Re: head, recursively through file tree?
    ... What's the problem with running a shell or perl inline script ... | child-process to execute the user's commands. ... the shell forks a process for every command it runs unless ...
    (comp.unix.shell)