• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Tell Blocks Considered Harmful (was Re: open for access)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: Tell Blocks Considered Harmful (was Re: open for access)
      • From: Chris Page <email@hidden>
References: 
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: Shane Stanley <email@hidden>)
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: Chris Page <email@hidden>)

  • Prev by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by Date: Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
  • Previous by thread: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by thread: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Index(es):
    • Date
    • Thread