Pro Tools and Admin Accts

by Scot Hacker

One of the reasons we looked forward to upgrading our Mac labs to OS X was the increased control we'd have over the systems in our multimedia lab. We carefully set up the lab machines with specific user-level capabilities -- users can run this but not that, open this preference panel but not that one, and so on.

And then we installed Digidesign Pro Tools 6.0. Guess what? It wouldn't run under the normal user account that every other piece of software on the machine ran under. A dialog (a DigiDesign dialog, not Apple) appears, reading the equivalent of: "You must have administrative access to run Pro Tools."

A closer read of the documentation confirmed that this is true. Requiring admin access to install software is one thing, but requiring it to run software is totally unacceptable. For one thing, Apple (and Unix history) have carefully created a system that would allow administrators to lock things down, so that users can run applications without danger of causing system-level harm. For this system to function requires a basic level of conformance to the platform's application model, to the understanding that users should be able to run the applications the administrators say they can run. And can do so without causing damage. Standards matter.

When an app vendor requires admin access to run a program, the sysadmin has a few choices:

  1. Not allow the program on the computer at all (not an option here)

  2. Give the user account admin access, thus subverting all the careful work the sysadmin has done to secure the system

  3. Create a separate account with admin privileges but minimal capabilities.

At first blush, option #3 seems like the ideal solution. But as we discovered, when you give an acct admin access, the "Edit Capabilities" button is grayed out. In other words, admin privs are an all or nothing affair. So it looks like #2 is where we're going to land - giving god-like privileges to all our unprivileged users just so they can run ProTools (an activity which consumes about 3% of the attention of the entire Multimedia Skills program).

And why exactly is it so damned important that Pro Tools be run with admin access? There's not a single other Mac OS X app I know of that requires this. Why is Digi special in this regard? I found this in Digi's knowledge base:

Does Pro Tools 6.0 require that Users have Administrator access?

Yes. Pro Tools is capable of creating and deleting huge files on a system, and if a user with no Administrator privileges isn't normally allowed to delete these files then Pro Tools shouldn't let him/her delete them either.

I'm shaking my head here. Final Cut Pro is creating files just as huge or huger, and it doesn't require admin access. And what exactly is it about deleting large files that is supposedly admin-specific? Since when can't normal users delete huge files? The simple truth is, no other user-level app on the platform requires admin access. This is just Digi making up their own rules, and getting away with it because of their position in the industry.

Security-wise, we're right back where we were with OS 9. Thanks for being such excellent platform citizens, Digi.

Am I missing something? Is there another way to deal with this problem, or is Digi being as obnoxious as I think they are?


2003-09-30 11:00:24
Amen Brother!
One thing that is only slightly less irritating is if a user doesn't have admin priv. MS Office X installs to a "Applications" directory INSIDE the user's home directory! And worse yet is that it doesn't warn you that it is going to put it in a non-standard location! No prompting for a Admin login to put it in the right place.
2003-09-30 11:04:21
man sudo
man sudoers
2003-09-30 11:05:39
Missed the good part
You cut out this part of their "Answer"

[quote]Historically this has always been the case with Pro Tools, whether on Mac OS 9 and previous (where there was only one user who had the equivalent of Administrator access), or on Windows NT, 2000, or XP.[/quote]

[paraphrase]Historically we've been stupid with this requirement of Pro Tools, whether on a secure OS or not so we are going to just continue on being stupid for the forseeable future.[/paraphrase]

2003-09-30 11:10:50
Switch to Logic.
Logic doesn't have these problems and is a much more sane audio production environment all around, imho.

It will also work with ProTools hardware if you happen to have that already.

2003-09-30 11:41:19
Trying to sudo Pro Tools to launch as admin does not work.
Pro Tools either detects the the current user is not admin or fails to launch with a string of error messages about not being about connect to the UI server or somthing like that.
2003-09-30 12:23:26
Everyone else jumped off the bridge, Mom...
(sigh) Sad to see this is happenning in the Mac world now. We have numerous enterprise applications that also "require" administrator privs on Win 2K clients. I explain to our group that this is not a requirement, this is LAZY programmers who fail to incorporate security into half-a## ports of Win 95 applications.
2003-09-30 12:27:11
Nikon Scan, too
I had the same problem with Nikon Scan 3. Fortunately, this was in a very small lab, and I just created an admin account named 'Nikon' for film scanning only. 9 out of 10 users were absolute novices on the Mac, and I flinched everytime I thought of them having admin privileges on a regular basis.

Nikon seems uninteresting in supporting OSX in general -- not unlike Digidesign, I think. Updates take a long time (4 months for the Jaguar fix).

2003-09-30 14:27:11
Nikon Scan, too
We had the same issue with Nikon Scan, but I'm not skewering them here because it was a bug and Nikon acknowleded it as a bug, even offered a workaround. They say it will be fixed in the next release of the driver. In Digi's case, it's intentional abuse of the platform standard.
2003-09-30 21:43:12
hack it
I don't know Pro Tools at all but the article makes it seem as if Pro Tools is insisting on admin status but doesn't really need admin privileges to operate. If it only does this check for admin status at application startup, a hack to make it work for non-admins might be to have a script that would temporarily add the user to the admin group, start Pro Tools and then remove the user from the admin group. That would limit the admin exposure to the short window while Pro Tools was starting up. Such a script would of course have to be suid. It would be more secure to make it a compiled application instead of a script.
2003-10-01 06:17:07
Use your buyer rights
The explanation given by the software maker shows incompetence and computer illiteracy. The buyer probably has the power to return the software and claim the money back on the grounds of receiving a product that is not what was advertised. Vendors cannot force such administrative priviledges because it wrecks systems security. Probably nothing short of getting the money back or switching to another vendor would make them realise their incompetency and act so as not to lose more customers.
2003-10-01 07:34:26
A Solution
This topic has recently been discussed on the DAW-MAC listserv. Someone recently posted a solution which seems to work.
Create a new user (not admin) with limited capabilities, Then in NetInfo Manager change their gid to 80 which is admin. I haven't heard any caveats to doing this.
2003-10-01 07:52:22
group 80
But if you make the user have group id 80 (admin), then the user will be an admin. Membership in the 'admin' group is what gives admin privileges.
2003-10-02 08:16:12
Amen Brother!
While it may be annoying that MS doesn't give an option to install using an admin password, but the /Users/username/Applications folder is certainly a standard location on Mac OS X.

It's a valid assumption. An admin user can install for themselves or for everyone. A non-admin user can only install for themselves, ie. into their own Applications folder.

Mr. Sharumpe

2003-10-03 15:03:59
PT 6 and Admin -- yes it is possible

I have a large number of Pro Tools systems that I administrate, and back when PT 6 first came out, I hated the fact that the users had to be admin level. After a couple weeks of working the problem, the solution was to use Netinfo and change the GID of the user to 80. This of course opens up huge security holes, and has presented a few persmissions problems, but I have been able to work through all of these issues and now have fully functional non admin users working away on PT 6.1. It is a "hack" to change the GID to 80, and plug up the holes that are left, but it works and its better than letting everyone have admin access to the system.
PT 6.1 is ok at best. It has bugs, and don't get me started about scsi and OS X, but the potential is there for a great system that provides protection to studio's and large installations that have users with "curious minds."

I have been using non-admin level users since March of this year and the system I have for creating the users and modifying there privliges and permissions seems to working well...