property theUser : "testuser" -- change this
property theGroup : "testuser" -- usually same as user (on Panther)
on adding folder items to thisFolder after receiving theseItems
repeat with oneItem in theseItems
set thePath to quoted form of POSIX path of oneItem
set chUserBit to "sudo find " & thePath & ¬
" -perm -u+x -exec chmod u+s {} \\; ; "
set chGrpBit to "sudo find " & thePath & ¬
" -perm -g+x -exec chmod g+s {} \\; ; "
set chOwner to "sudo chown -R " & theUser & ":" & ¬
theGroup & " " & thePath
try
do shell script chUserBit & chGrpBit & chOwner ¬
with administrator privileges
on error m
display dialog m
end try
end repeat
end adding folder items to
This Applescript needs to be copied to ~/Library -> Scripts -> Folder Action Scripts or /Library -> Scripts -> Folder Action Scripts in order to be recognized.
What it does: For each application that you put in the Sandbox folder, this script modifies its settings so that it runs as the testuser when launched. In contrast to the setuid approach, you only need to enter your admin password once when adding the app to the folder, and not on every app launch. And having a Sandbox folder to me just seems more intuitive.
How it works: When the setUID and setGID bits are set on an application, the app will always run as its owner, no matter who launched it. By setting both setUID and setGID and changing the owner and group to our unprivileged testuser, we achieve that the app runs as said testuser.
Notes:
- Avoid using root or any admin as the user unless you know exactly what you and the application are doing.
- Although it would be possible, for instance, to work with another user's iPhoto Library by copying the iPhoto app into the sandbox, this is not the use I intended. I recommend against attaching a user account that is already being used for productive purposes.
- I recommend you create some special user for the sandbox (non-admin of course; mine is called "testuser") whose exclusive purpose is to be used by the sandbox. This hint aims to provide untrusted apps with a secure environment where they can wreak havoc as they please and all they can damage is the "testuser" account.
- When an application opens another application, the latter runs as the current logged-in user (you), not as the testuser

