Re: Snow Leopard osax security and 'run script' with parameters
Re: Snow Leopard osax security and 'run script' with parameters
- Subject: Re: Snow Leopard osax security and 'run script' with parameters
- From: "Mark J. Reed" <email@hidden>
- Date: Fri, 8 Jan 2010 14:52:40 -0500
On Fri, Jan 8, 2010 at 2:25 PM, Stockly, Ed <email@hidden> wrote:
> Right, doesn't that make it less secure?
As I said in the paragraph you clipped, you have the same worries with
do shell script as with any dynamic code evaluation, including the
fact that you have to be paranoid about interpolating anything that
comes from the user. This is especially true since "do shell script"
is, like "do script", essentially an "eval", with no constraints on
what can be in the string other than legal shell code. Paranoia is
warranted.
Does the efficiency make it less secure? Well, I suppose since shell
commands often run much faster than the same task carried out via
AppleEvents, if you mess up you might do more damage before you
notice and abort the script..
> The small point I was making was that the argument against dynamic code
> generation was basically an argument in favor of other languages over
> AppleScript.
The argument is that AppleScript doesn't do dynamic code generation as
naturally as some other languages, so *if* your solution requires
heavy use of code generation, you might be better off using one of
those other languages.
Specifically, AS pretty much has only one way to do dynamic code: "do
script". This is, in this context, basically equivalent to what other
languages call "eval", which is the sledgehammer of the category. You
can put absolutely anything in the string you pass; which means if any
part of that string comes from the user, you have to make sure they
*didn't* put absolutely anything in there. Which is harder than it
seems.
More dynamic languages, even though they provide eval, usually also
have a more tightly constrained way to do dynamic evaluation. Ruby
has #apply (and symbols and Blocks and Methods and ...). Perl lets you
use the value of a variable in place of literal code in many contexts,
but maintains the knowledge of what the code is - if it's supposed to
be an identifier, then the value has to be an identifier, not
arbitrary code to be expanded in place as if it were a macro. Tcl
originally had only 'eval', but later introduced things like "upvar"
and "uplevel" to enable some of the more common uses of 'eval' to be
replaced by less dangerous constructs.
> For those of us who prefer AppleScript, dynamic code generation is often a
> viable and working option, whether it's in the form of script objects, do
> script commands or do shell script.
Yes, and sometimes those are the best way to accomplish a specific
task in AppleScript. More often with "do shell script" than with "do
script", I'd say. But that presupposes that you're already using AS.
If so, great. But if you know going in that the solution will make
heavy use of dynamic code generation, you might save some headaches by
using a different tool.
--
Mark J. Reed <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden