|
Otto Skorzeny posted:There's an old trick based off this where you put a file named -i in a directory to prevent yourself from accidentally rm -rfing it I like to live dangerously, I have a file called --no-preserve-root in my root directory.
|
# ? Jul 21, 2012 20:02 |
|
|
# ? Apr 29, 2024 10:34 |
|
Wheany posted:I like to live dangerously, I have a file called --no-preserve-root in my root directory. Am I wrong, or would doing that not make any difference? Anyway, I just use echo if I'm not sure about a wildcard expansion. And I hope I never see any directory with a file called "-r" or something.
|
# ? Jul 21, 2012 20:28 |
|
zergstain posted:Am I wrong, or would doing that not make any difference? Hmm, I don't actually know, let me check...
|
# ? Jul 21, 2012 20:35 |
|
You know, if only unix used / instead of - for command-line options, then you only have to be sure that one directory, the root directory, doesn't have a file named r and this couldn't happen...
|
# ? Jul 21, 2012 22:09 |
|
If you're worried about this, the fact that it's controlled by the shell gives you an easy out: if you're using bash, you can export GLOBIGNORE=-*, and now the shell will never expand * to include something starting with dash. You could quite reasonably argue that that should be the default.
|
# ? Jul 21, 2012 22:45 |
|
Be advised that setting GLOBIGNORE to a non-null value will cause * to start matching .* (except . and ..), so you'll probably want to set GLOBIGNORE to -*:.*
|
# ? Jul 21, 2012 22:50 |
|
But really, though, isn't that just piling workaround on workaround to get a fundamentally broken system working at that point, like this thread has so many times before (rightfully, imho) criticised, for example, PHP for? I'm not sure what the ideal solution would be, but at a guess I'd say that, at least in principle, the way Windows (and before that, DOS and CP/M) do it is the more correct one. The only reason it is so broken in Windows is (like with many things in Windows) because of layers upon layers of compatibility hacks and workarounds. But when starting from scratch I'd say a clean API for dealing with filenames and wildcard expansions that is well integrated with the APIs for opening and accessing files would be the cleanest approach. Alternatively, a clean way for applications to distinguish filename (and expanded filename) parameters from command flags might be a good solution, if the calling convention for the main program didn't just consist of a flat list of string pointers and could instead include identifyable data structures, so that an application be told, for instance, "this parameter, here, is a list of files." EDIT: vvv Well that's okay then, I'm not delusional enough to believe we're going to get out from under the weight of the Unix legacy any time soon even in those areas where it's more of a burden than a boon (and in all fairness to Unix, that's surprisingly few), but there were some people posting earlier in this thread saying that they honestly couldn't see what's wrong with shell-base wildcard expansion vvv PrBacterio fucked around with this message at 02:26 on Jul 22, 2012 |
# ? Jul 22, 2012 02:07 |
|
I think everybody agrees that the current system is poo poo, it's just that there's basically no way to make it not be poo poo at this point.
|
# ? Jul 22, 2012 02:10 |
|
PrBacterio posted:The reason it is a horror is because expanding arbitrary file patterns from the command line and passing them as a list of file names to an individual program can lead to unintended behaviour by that program when there are oddly-named files or no files matching a pattern. The individual application has no way of knowing whether any specific command line argument originates from a wildcard expansion of a file pattern or not and there is no one-to-one correspondence between actual command line arguments (as written by the user) and the command line parameter list (as seen by the program). isn't this what -- is for? It signals to stop parsing options after that point. code:
|
# ? Jul 22, 2012 04:10 |
|
Has anyone actually experienced this being a problem ever? I agree it's a bit of a horror, but it just seems like the least-impact horror I've ever seen. The bigger horror is probably naming a file after a command line option in the first place...
|
# ? Jul 22, 2012 04:16 |
|
It's entirely possible to have it happen by accident and it's not immediately obvious how to properly fix it without blowing everything up.
|
# ? Jul 22, 2012 08:29 |
|
I fail to see how it is different than any other user input sanitization issue, and that you should blame the shell, and not the user who blindly accept any kind of filenames without checking.
|
# ? Jul 22, 2012 09:15 |
|
PrBacterio posted:But really, though, isn't that just piling workaround on workaround to get a fundamentally broken system working at that point, like this thread has so many times before (rightfully, imho) criticised, for example, PHP for?
|
# ? Jul 22, 2012 09:17 |
|
Gazpacho posted:Well yes, I suppose, but the shell's purpose is to call out to programs that are free to do their own thing. PHP on the other hand is a closed system and pisses people off so much because its problems involve things that are under its own control. The issue here is that the way the shell calls out to programs that do their thing is the broken part. It's just that shell expansion and quoting rules are extremely hard to understand and misleading (you think bash quoting worked like it does in other languages? Hah.), and it's impossible for a program to tell whether an argument was explicitly specified or not. Any system that automatically builds a shell command line instead of an argv array to pass to execvp is usually going to be exploitable.
|
# ? Jul 22, 2012 09:22 |
|
This whole debate is loving pointless. Shell expansion is well defined and if you fail to read the docs or abuse your tools you're the only one to blame. You wouldn't call a hammer a horror because you keep hitting yourself everytime you try to use it. Well, you probably would. eta: ^^^ bash is poo poo though, don't use it. It's the hippie guitar version of a hammer. xf86enodev fucked around with this message at 09:37 on Jul 22, 2012 |
# ? Jul 22, 2012 09:33 |
|
xf86enodev posted:This whole debate is loving pointless. Shell expansion is well defined and if you fail to read the docs or abuse your tools you're the only one to blame. That's a completely retarded worldview if your goal is for software to work correctly or the shell to be used correctly. Your goal must be to have people memorize arcana and blame people whose planes crash because they flipped the wrong lever instead of blaming the people who made the cockpit design confusing. Which is what cockpit designers don't do, they blame the cockpit design when humans use them incorrectly, you don't glorify surprises in interface design and blame the user unless your goal is to just blame people.
|
# ? Jul 22, 2012 09:38 |
|
Maybe shell glob expansion should just insert a -- before it first applies.
|
# ? Jul 22, 2012 09:55 |
|
shrughes posted:That's a completely retarded worldview if your goal is for software to work correctly or the shell to be used correctly. "You want me to memorize all those levers and switches? Wtf!? I can't hook up my 360 controller?" You can't be serious. eta real CLI horror: code:
e2: And that's the thing. You can't design a system that's proof to human error. You can built-in safe-guards but you'll never get 100% safe. In the meantime you train people to know where their weaknesses are and where the systems have their pitfalls. xf86enodev fucked around with this message at 14:00 on Jul 22, 2012 |
# ? Jul 22, 2012 13:39 |
|
shrughes posted:Your goal must be to have people memorize arcana and blame people whose planes crash because they flipped the wrong lever instead of blaming the people who made the cockpit design confusing. Which is what cockpit designers don't do, they blame the cockpit design when humans use them incorrectly, you don't glorify surprises in interface design and blame the user unless your goal is to just blame people. Cockpit design has more complicated issues than that. Mainly that certain interfaces are standardised and it's what pilots are trained on. If you make a new interface you have to work through so many layers of international bureaucracy that it's deemed not worth the effort.
|
# ? Jul 22, 2012 14:55 |
|
xf86enodev posted:In the meantime you train people to know where their weaknesses are and where the systems have their pitfalls. Please point me to a an instruction manual for Bash that shows these common pitfalls, this is the first I'm hearing of it.
|
# ? Jul 22, 2012 16:04 |
|
would quoting every argument individually (and then escaping any quotes within the filename) work??? Or would that just eventually lead to mysql_escape_string_no_really_i_mean_it_this_time() style horrors?
|
# ? Jul 22, 2012 20:24 |
|
Jonnty posted:would quoting every argument individually (and then escaping any quotes within the filename) work??? Or would that just eventually lead to mysql_escape_string_no_really_i_mean_it_this_time() style horrors? I don't understand what you mean.
|
# ? Jul 22, 2012 21:16 |
|
Jonnty posted:The bigger horror is probably naming a file after a command line option in the first place... I've certainly done that by accident, and I know a lot of other people who have too.
|
# ? Jul 22, 2012 21:18 |
|
Suspicious Dish posted:I don't understand what you mean. I don't understand what quotes do in bash, ignore me
|
# ? Jul 22, 2012 21:27 |
|
MEAT TREAT posted:Please point me to a an instruction manual for Bash that shows these common pitfalls, this is the first I'm hearing of it. Didn't you see his post? You shouldn't even be using Bash (the most popular default shell that most new users are going to be exposed to and therefore learn) because it's terrible! Scaramouche posted:Don't know if this is laugh, cry, or just a disappointed, despairing sigh: Both the news and the tone of the article are worth a depressing sigh. Or maybe I'm misreading the Register's semi-typical lack of professionalism.
|
# ? Jul 23, 2012 15:29 |
|
http://cwe.mitre.org/top25/index.html OS injection is the number 2 vulnerability. Programs should not be spawning the shell, nor calling system. It's a poor choice of APIs that the correct way to do it both requires a fork and exec, and that we don't have a simple spawn API that takes an argv and double forks.
|
# ? Jul 23, 2012 17:05 |
|
In the year 2012, buffer overruns are still #3 on that list.
|
# ? Jul 23, 2012 17:32 |
|
ToxicFrog posted:In the year 2012, buffer overruns are still #3 on that list. I blame it on the C standard library. sprintf is in there, but asprintf is not.
|
# ? Jul 23, 2012 17:34 |
|
New project from Boss! It involves raw sockets in PHP. So of course I open it up and hang on, this isn't boss's style at all. I mean, it has comments. And not just the "//lineofcode()" kind, either, but actual comments! code:
The code is incredibly hacked up, but it's funny that it still works. Case in point, you can leave a dangling string out and PHP does not give a gently caress: code:
The rest of the code is similarly hacked up, with a lot of randomly commented things, magic numbers, and all sorts of other good things. Today is going to be a long day.
|
# ? Jul 23, 2012 19:03 |
|
Zamujasa posted:Reminds me of my last job where I'd see code that was literally just "1;", as if it did something. It does something in perl: http://stackoverflow.com/questions/5293246/why-the-1-at-the-end-of-each-perl-package
|
# ? Jul 23, 2012 19:10 |
|
Zamujasa posted:Case in point, you can leave a dangling string out and PHP does not give a gently caress:
|
# ? Jul 23, 2012 19:30 |
|
het posted:You can do that in perl, ruby, and python too btw. I figured. (Probably in a lot of other languages.) But in the case of PHP, I think it just describes how sloppy he (and others) can be. There are a lot of other horrors in this code (like replacing binary data with boss's favorite ASCII markers, then switching back, because that data will "never occur"), though.
|
# ? Jul 23, 2012 19:36 |
|
Suspicious Dish posted:I blame it on the C standard library. sprintf is in there, but asprintf is not. I guess it counts as a horror that on this platform, a problem I had to clean up again and again was local string buffers sized according to the maximum filename length, which had nothing to do with filenames. And this at more than one company, it wasn't an issue with a particular programmer. Gazpacho fucked around with this message at 20:43 on Jul 23, 2012 |
# ? Jul 23, 2012 20:35 |
|
het posted:You can do that in perl, ruby, and python too btw. Pretty sure you can do it it C.
|
# ? Jul 23, 2012 20:36 |
|
Zombywuf posted:Pretty sure you can do it it C. You can; gcc and clang will point it out as a warning, but it works just fine.
|
# ? Jul 23, 2012 20:42 |
|
Gazpacho posted:I can assure you that the real problem is programmers just not knowing what memory is. Every time I hear "Out Of Memory crash? But my machine has plenty of RAM!", I die a little on the inside
|
# ? Jul 23, 2012 20:49 |
|
I'm going to bump shellchat while it's on this page. I've always used bash, probably because it's been Debian's default for a while. But if it sucks, what shell should I be using instead?
|
# ? Jul 24, 2012 12:13 |
|
I use rc (among other things) from plan9port.
|
# ? Jul 24, 2012 16:13 |
|
Kim Jong III posted:I'm going to bump shellchat while it's on this page.
|
# ? Jul 24, 2012 17:24 |
|
|
# ? Apr 29, 2024 10:34 |
|
Kim Jong III posted:I'm going to bump shellchat while it's on this page. I use zsh on most of my machines, unless it's not available. In that case I tend to use tcsh, ksh or csh (in that order or preference). I'm not actually sure why, it's probably because I learned to computer that way. And I cannot live without "bindkey -v" to enable vi-like editing. If somebody has an actual valid pro/cons table of zsh vs bash vs (t)csh I'll be the first to read it.
|
# ? Jul 24, 2012 19:49 |