|
Personal tools |
|
|
/Talk:User Guide/Environments
From Annvixjf: environment directories more secure? No way. At least, not in the way that you mention. Just as sysconfig files can be easily editted, so can environment directory files! The only difference here is programmability - it's much easier to script, or adjust parameters on the fly easily without needing to write some "config file parser". And of course, it's much easier to come up with your own program to make use of environment variables, without having to (again) write and invent your own parser and config file format.... That's about it. Programs end up being more secure than if they had been written with parser code in as well - but for programs already written, I hardly think it really makes any difference. Except perhaps as mentioned, for scriptability. Here, everybody wins here. Both the good guys... and the bad guys. I think you misunderstoodI think you misunderstood the whole point of environment directories vs configuration files, or you didn't read the whole thing. The point isn't to make something less easily editable... that's not the point at all. The point is hiding code that can be executed. With a sysconfig file (a file that bash sources when required to get configuration data), one could hide extra commands. So by editing /etc/sysconfig/i18n, I can make the system start a rootkit, trojan or whatever and there is no effort... it's "hidden" in the sysconfig file and will always be executed at boot (or anytime that file is sourced by bash). Using an environment directory where one file contains one thing (the file is the name of the variable, the contents are the value of the variable), you're no longer sourcing (or executing) the file. All you're getting is the value of the variable, if it's a script or code, it's contents become the value of the variable, unexecuted, and even then only the first line is ever looked at. Nothing is executed at all. This has nothing to do with scriptability, parsing, or anything like that. This isn't about convenience. This isn't about "winning"... this is about the right way to do things. Instead of theorizing on how the good guys "win" and the bad guys "win" (which you did not illustrate whatsoever), prove it with practical examples as to *how* the bad guys can do anything with this other than change the value of a variable (which is far less damaging than being able have code executed everytime the file is sourced). (jf: ok, gotcha!) - sorry about that - apparently you're right! I had thought that you might still be able to do something with the `head -n1 VARFILE` thing, but apparently, you can't... As you mentioned, only the contents of the variable gets changed - but it is not a case of "totally trusted execution", like in the case of /etc/sysconfig/*. As for "how" the good guys "win"... I believe I've explained that already. |
![]() |
|
| ||