Your missing the point of the bug report. The authorization key for Finder Authentication isn't in/etc/authorization. Their own API is incomplete. If it was there, a sysadmin could change it to only allow wheel or some other group to gain root access through the Finder. You could add the key, but if Apple ever does fix this, it could screw things up down the road.
What I meant by not recognizing file permissions is if I set a folder to root:wheel so only root should have access, Apple's API, in it's current state, allows for admins to bypass my permissions. For that matter, Apple's current API allows admins access to/private/root and anything else that is root only.
If Apple's idea is to make any admin a root-equivalent by default, I have a hard time seeing them taken seriously in secure environments without giving sysadmins more control over the API. Sudo gives this control. Apple's API does not
But the file system does. Why bother assigning root:wheel permissions if your own security API doesn't recognize them. This is an on going debate - Apple has two security APIs, the standard UNIX file permissions, and their own. Problem is their own is not complete as you can see from my bug report, and it is poorly documented for sysadmins. The UNIX permissions work just like their supposed to, but the get trumped by Apple's.
"files/System/Library is root:wheel; 755, so that mitigates an OS-level attack"
Not entirely true. 10.3 includes a new "Finder Authentication" feature that allows admin users to authenticate and receive root privileges even if the admin group is removed from sudoers. I've submitted this as a bug to Apple...no response. Here's my longer description...
I think when it comes to automating applications AppleScript is more powerful than people realize. However when it comes to system scripting, shell and perl scripts are still the way to go. I recently wrote a login script that I prototyped as a shell script and then wrote out as an AppleScript. I ended up using the shell script. Much smaller and easier to write. Simple commands like echo and grep take many, many lines of code in AppleScript. Even complicated tools like awk are still easier to write out than the equivalent AS code. As I become more familiar with perl and python, those might even be a better way to do system scripting.
You can manipulate files with resource forks in the shell using the MacCp, MacMv, and ditto commands which will preserve the resource forks.
Or it could be the opposite...Kill all other Mac development and concentrate those resources into VPC for the Macs. Make it fast and stable and then tell Mac users if they want to run Office, Outlook, or IE, buy VPC. They'd make for more money that way.
Slashdot Mirror
What I meant by not recognizing file permissions is if I set a folder to root:wheel so only root should have access, Apple's API, in it's current state, allows for admins to bypass my permissions. For that matter, Apple's current API allows admins access to
If Apple's idea is to make any admin a root-equivalent by default, I have a hard time seeing them taken seriously in secure environments without giving sysadmins more control over the API. Sudo gives this control. Apple's API does not
But the file system does. Why bother assigning root:wheel permissions if your own security API doesn't recognize them. This is an on going debate - Apple has two security APIs, the standard UNIX file permissions, and their own. Problem is their own is not complete as you can see from my bug report, and it is poorly documented for sysadmins. The UNIX permissions work just like their supposed to, but the get trumped by Apple's.
Not entirely true. 10.3 includes a new "Finder Authentication" feature that allows admin users to authenticate and receive root privileges even if the admin group is removed from sudoers. I've submitted this as a bug to Apple...no response. Here's my longer description...
http://www.securitytracker.com/alerts/2003/Nov/100 8278.html
I think when it comes to automating applications AppleScript is more powerful than people realize. However when it comes to system scripting, shell and perl scripts are still the way to go. I recently wrote a login script that I prototyped as a shell script and then wrote out as an AppleScript. I ended up using the shell script. Much smaller and easier to write. Simple commands like echo and grep take many, many lines of code in AppleScript. Even complicated tools like awk are still easier to write out than the equivalent AS code. As I become more familiar with perl and python, those might even be a better way to do system scripting.
You can manipulate files with resource forks in the shell using the MacCp, MacMv, and ditto commands which will preserve the resource forks.
Or it could be the opposite...Kill all other Mac development and concentrate those resources into VPC for the Macs. Make it fast and stable and then tell Mac users if they want to run Office, Outlook, or IE, buy VPC. They'd make for more money that way.