Re: Tell Blocks Considered Harmful (was Re: open for access)
Re: Tell Blocks Considered Harmful (was Re: open for access)
- Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
- From: Ed Stockly <email@hidden>
- Date: Sun, 14 Dec 2008 14:53:43 -0800
Ok, so first it's one thing to encourage users to not put osax calls
within application tells, it's quite another to advocate breaking that
behavior and radical changes in the compiler to "fix" that behavior.
I'm wondering if everyone on the list understands that commands like
these are all part of what is being discouraged here:
tell application "Finder" to set myFileName to name of (choose file)
tell application "Finder"
set myFiles to every file of (choose folder)
set the name of myFile to the text returned of (display dialog
default answer "File Name")
set the name of myFile to date string of (current date)
set myFile to every file of (choose folder) whose modification date <
(current date)
set myCase to ASCII character of character 2 of the name of myFile
end tell
--a simple one line command becomes 2 lines
set myFile to choose file
tell application "Finder" to set myFileName to name of myFile
--additional variables are needed
set folderRef to choose folder
tell application "Finder"
set myFiles to every file of folderRef
end tell
-- some scripts becomes less readable, less accessible
set currDate to current date
set folderRef to choose folder
tell application "Finder"
set myFile to every file of folder whose modification date < currDate
end tell
And, of course, these examples are totally isolated. Make these
changes in a script of any complexity and it becomes worse.
CP>>2. The dialog is modal and prevents the user from interacting
with the target application.
SS>>I'd be sad to see that go.
CP>>Why is that important for your scripts? Is it critical for
correct operation or just nice-to-have? Do you need to be able to
prevent the user from interacting with the target application?
First, remember that we're often scripting multiple applications:
Finder, Filemaker, InDesign and PhotoShop all in one script, heck
maybe even in the same tell block.
In one case I may include all the UI related commands in the Finder,
but that may be an arbitrary decision. I would hope to avoid the
delays required whenever the UI focus is changed, so, if the script is
launched from within InDesign, for example, then all the UI commands
would be sent to InDesign. And yes, it may be critical that the user
doesn't interfere when a script is running.
3. The contents of the file-related commands depend upon the
permissions of the target application.
I'm still trying to get my head around the idea that the apps
*have* different permissions -- I don't think I've seen the issue
raised in a practical situation. I may be wrong, but I suspect this
is a complete non issue.
What's the complete opposite of “non-issue”? That's what this
is. ;-) The exploit I fixed earlier this year in Security Update
2008-005 involved processes with different permissions.
Just to give the conversation some context, one of the most advanced
and experienced AppleScripters (Shane) sees this as a complete non-
issue, and I agree, for AppleScripters this is a non-issue. It is such
a non-issue that most of us are not aware of it.
Here's how I'd assume it would be handled. AppleScripts are always
launched from within some application. Either the finder, or an
applications scripts menu or a system process.
Even if they're sending commands to a process with additional
privileges, they should not have privileges beyond their inherited
privileges without some kind of authorization.
If launched from the finder they should not have permission beyond
what the user has in the finder, and the same should be true for any
application or process.
If you sent one of these other processes a ‘do shell script’ command
it would execute that command using the privileges of that user
instead of yours.
I can see how shell scripting can open a new dimension of challenges,
but the shell scripting mechanism also has ways of passing a user or
administrator password that can allow additional privileges.
I would really hate to see the entire language munged just to allow
for an additional vulnerability introduced by 'do shell script'
The exploit I fixed earlier this year in Security Update 2008-005
involved processes with different privileges. ARDAgent sometimes has
root privileges (when its user id is root). The exploit that got
everyone's attention was sending it ‘do shell script’, but it would
also have been a security problem if you had sent it ‘choose file’,
because you would be able to see inside directories you don't
normally have permission to look inside (e.g., other user folders).
Worse, ‘choose new file’ displays a dialog with a “New Folder”
button, enabling you to create directories owned by root, within
directories you don't permission to modify.
Has that fix broken many scripts in the wild?
I don't mean to be disagreeable, but seriously there must be a better
way.
I would suggest limiting permissions and privileges to whatever the
current user and the current application have, and require additional
authorization to go beyond (either a user password or a password
embedded in the script).
And let us keep writing osax commands in tells.
As for users not knowing if it's the finder that displays a file
dialog or an osax, that's part of the zen of appleScript.
We can write scripts that work and not know all the details or even
the basics about how things work, and our scripts work. As we learn
more about scripting those details reveal themselves.
ES
_______________________________________________
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