Electronics & Computers Deals here!
Applications inexplicably running as root (cont.): Checking which apps use setuid, more
We continue to investigate a phenomenon where normal applications inexplicably run with root privileges. As noted yesterday, this is a potentially serious security concern, as apps running with such privileges can manipulate data beyond their intended bounds and potentially wreak system havoc. It's indicative of an inadvertent invocation of the setuid command -- which can be invoked to allow applications root privileges on a case-by-case basis.
Also as mentioned yesterday, you can check which applications are running with which privileges using Activity Monitor, located in /Applications/Utilities. Click the User tab to organize by this field. If you find normal applications running as root.
Fortunately, under Mac OS X 10.5 (Leopard) there's also an easy method for determining which applications have assigned themselves root priveleges via the setuid command. Launch the Terminal (located in /Applications/Utilities) and enter the command:
- sudo /usr/bin/setuids.d
then press return (thanks Dominic Dunlop).
Generally, only core system processes (such as java, update, coreaduiod, etc.) should run as root. All ordinary, Finder-launched applications (Preview, Safari, iPhoto, the Finder itself, etc.), should usually run under the activating user. If you see any suspect listings after invoking this command, you can use Activity Monitor to quit the processes.
A few more reports on this issue:
One MacFixIt reader reports a situation where the application Color launched under the root account, and actually saved files to the root user's Library directory:
"Oddly enough, I had the same thing happen yesterday with Color, but v 1.01 under 10.4.10. The app crashed, and on relaunch it ignored the current user prefs, instead opening with the home directory hierarchy, which Color and Final Touch users will recognize in its arcane glory, defaulting to the Documents folder of the root user, despite not being enabled in Netinfo. All saved grades etc ended up in Users/root/Library/Application Support/Color. The user prior to this event was an admin user, which may have something to do with what on the face of it looks like an escalation of privileges, at least within the app. Very odd indeed."
Another reader reports that he found the Finder running with root privileges:
"Coincidentally I noticed this morning as I cleared my overnight screensaver that in the Finder window sidebar my 'Places' listed 'root' next to the 'home' icon, and the list of other folders I have there wasn't there any more. Fearing the worst, when I moved the mouse to investigate, the Finder 'blinked' and my home directory and other folders reappeared as usual. I then saw your article on root applications and decided to investigate - there are a number of system processes listed as running as 'root' (such as Mozybackup, aspects of Retrospect, my UPS client) - but also Finder."
One reader questionably posits that DiskWarrior is responsible for applications incorreclty running with root priveleges:
"I made the mistake of running DiskWarrior on my 10.5 disk while booted from a from a 10.4 disk and had the same problem of various programs running as root afterwards. I suspect that repairing permissions from DW was the primary cause."
Feedback? Late-breakers@macfixit.com.
Resources
:%20Checking%20which%20apps%20use%20setuid,%20more%20%7C%20MacFixIt%20-%20CNET%20Reviews&srcUrl=http://reviews.cnet.com/8301-13727_7-10329213-263.html){kind=small}
It is not required that an application (Retrospect) would need to be running as Root to read a file. Root would only be required if it was necessary to write a file anywhere, modify a file anywhere, or delete a file anywhere. Reading is not a Root requirement.
All files have permissions which can control access for read and write purposes. There are many files and folders on a standard Mac OS X system which cannot be read as an admin user, and if you have multiple users on your computer then one admin user cannot read another user's files. You need to become root in order to gain complete read access to everything, e.g. in order to do a full system backup.
It is therefore necessary for at least some parts of Retrospect to be running as the root user, even if you are only doing a backup. For a restore operation, it definitely needs to be root, because that gives it the unconstrained ability to set file ownership and permissions.
There is a potential Armageddon creating utility there named Tech Tool Pro which will run like 5 resident modules without figuring the guy installed 10.5 and Disk Warrior is mentioned.
I wished Alsoft was large as Micromat and called CNET about this horrible misinformation propaganda. A disk utility will need exclusive rights to disk and will need Admin (root) permissions. WHAT A BIG DEAL!
If you bundle Techtool Pro with your subscription Macfixit guys, we will figure the reason why Diskwarrior is being victimized by you.
STOP hurting small companies without reason. I will be contacting Techtracker founder about this. Someone didn't get support job from Alsoft or something?
- by John Sawyer December 1, 2007 12:08 AM PST
- It should be noted here that Diskwarrior doesn't repair permissions by default--you have to select Diskwarrior's "Files" option for that. Otherwise, it just repairs the volume's directory, which also fixes various file issues like custom icons, text encoding, extended attributes, etc. (I don't know why those things aren't lumped into the "Files" option).
- Like this Reply to this comment
-
(6 Comments)