2010 iMac running 10.9.1

Ran Repair Disk Permissions and got this:

Warning: SUID file “System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent” has been modified and will not be repaired.

My 10.9.1 is not misbehaving -- so far as I can tell. What's up with that warning?

Repair Disk Permissions messages that you can safely ignore.

I realize that article doesn't really answer the question "What's up with that warning?", but I don't have the time right now to track down the more extended discussions on the subject that have occurred here at FTM (and, earlier, at MFIF).

That was also one of my early queries when adopted OS X Lion a little over 2 years ago. The article referred to is a good one; it applied all the way back to OS X Leopard.
The real question is: Why hasn't this been fixed before OS X Mavericks?!

Add to that the obnoxious (and identical) spate of permissions repairs which show up every time Disk Utility is run — pretty much the same list referenced in the article. One would think that the repairs should 'take', but they don't, if in fact they are 'real'.

Thanks. I should have checked the published list of "pay no attention" oddities re: repairing disk permissions.

Gee Grelber where were you back in the OS X Public Beta and OS X 10.0 when the "safe to ignore" repair permissions error/warning messages first started? From time to time they have disappeared, but generally only because Disk Utility or rather the underlying Unix command was coded not to report them (the messages were still generated, but Disk Utility simply didn't report them). I once read an article that purported to explain why new ones show up in each new iteration of OS X, but by that time I had long since learned to ignore them so I didn't pay enough attention to remember the explanation. I just figure that the sun will rise in the east each morning and new ignorable permissions warnings/errors/messages will appear with each update/upgrade of OS X. It is inevitable.

Why, Grelber was happily basking in the warm familiarity of his decade with Mac OS 9.


Inevitable perhaps, but at times also annoying because those recurring and ignorable warnings/errors/repairs obscure new ones you might be interested in for troubleshooting purposes. After all, who knows that persistent set by heart? I sure don't, so I'd have to look it up to be able to see the forest for the trees.

Neither do I, but I certainly recognize this one.


This one seems to have been around since Attila the Hun was in third grade and it always shows up near the end of that very long ever-changing list. So, I make use of it. When I'm doing Permissions Repair I find that the time Apple allots is never right (like saying 6 minutes continuously for 20), so I do something on my iPad while I wait.

When I see the above, Warning:SUID File, I know it's near the end and I should wrap up whatever I was doing to kill the time.

Aw, you beat me to it.

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."

Thanks for that; I think it's the first time the SUID issue has ever been explained.

Edit: So, DU's reporting actually does have a reason...to let us know that something has been changed so we can "rule" on it.

Yes....ditto on the Thanks for that.