• 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: Chris Page <email@hidden>
  • Date: Sun, 14 Dec 2008 05:11:46 -0800

On Dec 14, 2008, at 9:39 PM, Shane Stanley wrote:

On 14/12/08 8:30 PM, "Chris Page" <email@hidden> wrote:

2. The dialog is modal and prevents the user from interacting with the target application.

I'd be sad to see that go.

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?


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.


Every process potentially has different privileges and rights from every other process. Processes with different user or group ids have different privileges. If you open Activity Monitor, tell it to display All Processes and look at the User column, you'll see processes owned by several different users. In addition, processes may be granted specific rights to perform certain operations. For example, when System Preferences asks for your password to change certain preferences, the System Preferences process acquires a right named “system.preferences” which allows it to modify system-wide preferences that may affect all users.

The next time you see a password dialog, click on the triangle to open the Details section. The “Right:” shows you the name of the right that you're being asked to authorize. If your computer requires a password to unlock the screensaver, you'll see that the password dialog is asking for the “system.login.screensaver” right. Instead of granting processes broad “admin” or “root” privileges, they are granted specific rights to perform specific operations as needed. You can see various rights in the authorization database, which is in the plist file “/etc/authorization”. See the man page for the “security” command for more information (search for “authorization” and “authorizationdb”).

WindowServer, which displays all your windows and handles mouse and keyboard input, is owned by user _windowserver. SecurityAgent, which displays the password dialog, runs as user _securityagent. If you turn on Web Sharing, the web server, httpd, is owned by _www. In addition, many processes are owned by root, the user with the right to do practically anything to any file or to any other process. Generally, unless you open a bunch of applications, processes owned by you are in the minority. And, of course, other human users can own programs running on the same computer, e.g., using Fast User Switching or ssh.

Some human users also create alternate user ids to perform certain tasks. If you open Terminal, you can login as another user and run programs, which will be owned by that user, even while you're still logged in, without using Fast User Switching.

Processes are arrange this way to grant some rights and limit others, and to protect them from other processes.

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. This is a security problem (specifically “privilege escalation”) if, for example, that other process has the ability to access or modify files that you don't. Alternatively, it's a compatibility problem if someone sends an event to a process without the right to do what is asked of it.

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.

Very generally speaking, if a process owned by you can tell a process not owned by you to perform file operations or other I/O, non-admin users may be able to do what only admin users are supposed to be able to do. And even when two processes are owned by the same user, they may have additional rights or limitations imposed upon them that they shouldn't be able to get around by asking other processes to do things on their behalf.

I think it'd be a shame, but it does have a silver lining: people have often asked for a way to run a script, have it pause while they do something, and then have it resume. That's what your proposal offers, I guess.

But what happens in the case of scripts run from apps' script menus or palettes? In publishing, that's a fair percentage of scripts.

I don't quite follow you. Currently, if you run a script within an application and it does ‘display alert’, the dialog will be within that application and it will be modal, preventing the user from interacting with that application. If the script tells Finder to display the alert, the dialog is within Finder and the user can't interact with Finder or the Desktop, and the script pauses until the user dismisses the dialog. Depending on the application running the script, it usually also means that application doesn't respond to user input while the script is paused, either.


What I'm suggesting is, when ‘display alert’ is inside a Finder tell block, what if the dialog weren't displayed in Finder's process? The user would be able to interact with Finder while the dialog is displayed. But the script would still be paused waiting for the response, and the application running the script would still be waiting for the script to resume execution.

We could accomplish this either by displaying the dialog inside the application running the script or by creating another process that exists specifically to display dialogs for scripting addition commands. In either case, the script pauses and the application running the script pauses until the user dismisses the dialog.

And the clipboard's dictionary says in part: " Use in a ‘tell’ block..."

I wonder if that documentation is out of date.

It could be -- in any case, the context is in terms of activating the relevant app.

My point is: Do the clipboard commands work correctly without a tell? Does it matter which process they're handled by? Is it necessary to activate an application and send it clipboard commands for them to work correctly? It used to be true that the clipboard could only be accessed by the active application process, but I don't know whether that's still true.


--
Chris Page

 The other, other AppleScript Chris

_______________________________________________
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: Ed Stockly <email@hidden>
    • 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: Paul Berkowitz <email@hidden>
References: 
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: Shane Stanley <email@hidden>)

  • Prev by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • 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