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: 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