----- Original Message -----
From: "Randall R Schulz"
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@aljex.com http://profile.to/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org