What is it that we "know"?
If it's an Apple
bug, why not say so?
Does linking to the Apple KB not suffice?
Nope... not in terms of making members aware that the underlying cause is a bug. The word 'bug' doesn't appear on that page, nor does Apple acknowledge that the issue is abnormal. Quite the opposite, everything along those lines gets swept under the carpet.
Are you under the impression that every kbdoc is about an Apple bug?
Am I training people? Of course we don't *know* if it can be ignored. But unless the user is experiencing a problem, why not ignore them? If the user came in and said: "I am having issues with ARD and Java" then sure, it may be necessary to dig deeper.
In regards to not knowing why, I know exactly why, because Apple says: YOU CAN SAFELY IGNORE THESE MESSAGES. Now, if the particular message you are getting is not the same, then there can be cause for concern. For example if the permissions that are on the file differ drastically from what is expected.
"Drastically different permissions" huh? Well, let's just see about that. Remember this bit from post #1?:
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.
Tell me...
- What are the "permissions" on ARDAgent (on skate71290's machine) then, and how do you know that?
- What "modifications" has that item (on skate71290's machine) undergone, and how do you know that?
The reality is: neither you, nor i, nor Apple actually know (until we look).
Give me a break. First of all, the real shame are the multitude of self proclaimed "geniuses' who waste no time telling people to repair permissions.
That's the typical preachy cop out. Whether run once a year or once a day, there's
no excuse for Disk Utility to produce spurious messages. Now you're trying to shift the burden of that responsibility onto users (and attempting to change the subject in the process... this is not a debate about whether or not verifying permission settings is a worthy troubleshooting technique).
The fact is, no one should be doing it as often as they think they need to. If people would quite perpetuating this "fix," most users would never even see these messages.
I see... so you blame Apple's bogus messages on users repairing permissions "too much"?
And I must say this:
the list of files with which hackers can freely tinker (because users are instructed that those are items to simply ignore).
has to to be one of the most idiotic things I have read. How do those things even relate? The instruction to ignore permission errors that match what is shown here:
http://support.apple.com/kb/TS1448, in no way suggests that the user can freely "tinker."
Do you even know what an 'suid' file is? (and the ramifications of what a modified suid file might portend?). Have you witnessed how DURP will not even
unset the suid bit from a file which
shouldn't be suid? I have (and can link to those threads as well). In those cases, /sbin/launchd had been suid during some users' Leopard upgrade. Launching TextEdit for example would run as root, and thus save root-owned documents. DURP
refused to unset those bits. [i don't want to spend more time on all this right now... but believe me: hackers have far more imagination and ideas about how to exploit such scenarios than you seem able to accept.]
As I stated above, less aware users should never have to even open Disk Utility if people would stop perpetuating the myth that it is necessary to repair permissions.
You're still hung up on that "myth" myth? You would rather continuously harp about cat poo than simply mention that the post #1 messages are due to an Apple bug? You'd rather train generations of Mac users to "
safely ignore suid warnings" as you link to that kbdoc with no further elaboration? That's your call then.
To close, if you want this fixed, quite posting rants here and report it to Apple and request a fix. It is worthless to post this here. Also, I won't be spreading any "word." If a user is experiencing issues with something related to the particular file or folder in question, I will dig deeper. If not, then as Apple says: You can safely ignore it. If you have a problem with that, take it to Apple.
Apple surely is well aware of this. Their answer (until they fix it)
is that kbdoc. They can afford to put it on the back-burner because most users don't realize what's behind all this... therefore i am trying to inform users.
So far, the only obstacle to my mission comes from people who can't stop preaching about how "users repair permissions too much". Dude... you skipped right over this:
an assortment of false messages which only mislead users who might also happen to be experiencing real issues
See... this bug screws with everyone, even users who *are* having problems.
Perhaps the situation is harder to evaluate accurately while standing on a soapbox.
