Q: I ran the disk utility on my Yosemite 10.10.2 and it gives me a warning: "SUID file "System/Library/CoreS...has been modifie ... I ran the disk utility on my Yosemite 10.10.2 and it gives me a warning: "SUID file "System/Library/CoreS...has been modified and will not be repaired. Can I fix this myself? more
-
All replies
-
Helpful answers
-
May 26, 2015 6:46 PM in response to rosemaryfrommoby Niel,Click here and check if your message is one of those listed. If it is, there's nothing to fix.
(127935)
-
by Linc Davis,May 26, 2015 6:46 PM in response to rosemaryfrommo
Linc Davis
May 26, 2015 6:46 PM
in response to rosemaryfrommo
Level 10 (208,000 points)
ApplicationsAlthough it’s immensely popular, repairing permissions is a waste of time unless you have a specific indication of a permission error involving system files, which is rare, or a startup failure. It has traditionally spewed bogus warning messages that mean absolutely nothing.
The built-in help for Disk Utility reads in part:
If you see an alert or a message that says your permissions are set incorrectly, you can correct the disk’s permissions by clicking Repair Disk Permissions.
It’s justifiable, though rarely necessary, to repair permissions after running a third-party software installer, as defective installers have been known to damage the permissions of system files.
-
May 27, 2015 10:16 PM in response to Linc Davisby Vishal2014,Agree and Disagree. Disk Utility repairs the issue which it can cover up. When it doesn't it gives up.
-
Jun 19, 2015 7:20 AM in response to rosemaryfrommoby URBAN_GENIUS,Unfortunately I can't offer a resolution to the problem. I too have run into this issue after some odd issues I have been experiencing with my Late 2011 MBP.
This is the most reasonable explanation to the SUID problem I have come across. It was written by user "tacit" from Portland, Oregon, USA on 08/03/09. You can find the original thread on: http://www.finetunedmac.com/forums/ubbthreads.php?ubb=showflat&Number=27972 This is what he said:
...So for a bit more information:
SUID (Set User ID) is a special Unix permission bit. Normally, when you run a program, it runs with whatever level of permissions you have. If you run something from a limited account, it has limited permissions. If you run it from a guest account, it has whatever permissions the guest account has.
Sometimes, a program needs to do things that a normal user doesn't have permission to do. For example, a program might need to open a port on the network, which is (usually, depending on the port) something only a privileged account can do.
Set User ID means "when you run this program, don't run it as the user. Run it as though it were started by this other user instead." If you run a program that's intended to do anything, it might run as root, rather than as you. (This is bad form, but it's theoretically possible).
Sometimes, this can create a problem. For example, the Apple Remote Desktop needs to be able to communicate over the network and intercept certain device I/O calls (say, to let another person move your mouse pointer). So it can't run as you. It has to run as a user with more privileges than a normal user account. So it has SUID as a privileged user.
A past version of OS X had Apple Remote Desktop suid root. This created a security hole; it was possible for a hostile attacker to send commands to Apple Remote Desktop (specifically, AppleScript commands) that it would execute as root, potentially giving up access to the computer. So Apple changed the suid so that it ran as a different user, one more limited than root.
Disk Utility's permissions repair recognized that an Apple update changed the suid of Apple Remote Desktop. It didn't change it back to the way it was before the update,
-
Jun 19, 2015 9:45 AM in response to URBAN_GENIUSby URBAN_GENIUS,Oops, left out the last two sentences from his original post. Here it is:
So for a bit more information:
SUID (Set User ID) is a special Unix permission bit. Normally, when you run a program, it runs with whatever level of permissions you have. If you run something from a limited account, it has limited permissions. If you run it from a guest account, it has whatever permissions the guest account has.
Sometimes, a program needs to do things that a normal user doesn't have permission to do. For example, a program might need to open a port on the network, which is (usually, depending on the port) something only a privileged account can do.
Set User ID means "when you run this program, don't run it as the user. Run it as though it were started by this other user instead." If you run a program that's intended to do anything, it might run as root, rather than as you. (This is bad form, but it's theoretically possible).
Sometimes, this can create a problem. For example, the Apple Remote Desktop needs to be able to communicate over the network and intercept certain device I/O calls (say, to let another person move your mouse pointer). So it can't run as you. It has to run as a user with more privileges than a normal user account. So it has SUID as a privileged user.
A past version of OS X had Apple Remote Desktop suid root. This created a security hole; it was possible for a hostile attacker to send commands to Apple Remote Desktop (specifically, AppleScript commands) that it would execute as root, potentially giving up access to the computer. So Apple changed the suid so that it ran as a different user, one more limited than root.
Disk Utility's permissions repair recognized that an Apple update changed the suid of Apple Remote Desktop. It didn't change it back to the way it was before the update, because Disk Utility has no idea *why* it had been changed. If Disk Utility were to blindly change permissions back, it might re-create a security hole that had been fixed! So it tells you "this has changed; I'm not going to change it back."