We had a problem with this starting with one of the later 10.4.x
releases.
After much difficulty, we determined that we had set the TMPDIR
environment
variable, but later had removed the folder where TMPDIR points.
This was
the problem.
You should make sure TMPDIR is set to an existing location, or
remove it
from the environment.
If that is not the problem, try using Shark to see what system
calls are
being made. We also used ktrace/fs_usage to see what file accesses
were
made.
Paul Nelson
Thursby Software Systems, Inc.
on 9/17/07 9:26 AM, Ken Aspeslagh at email@hidden wrote:
Hi Perry:
Many thanks for your reply and suggestions. I understand that
it's the
unexpected error code and there's no way to know for sure where
it's coming
from.
I'm still hoping that someone out there may have had some
experience seeing
this error resulting some specific bad configuration and could
share on of the
potential causes.
Meanwhile, I'll have them make a new user. I doubt they'll agree
to reinstall
their system! ;)
Regards,
Ken
-------------------------------------
"The major difference between a thing that might go wrong and a
thing that
cannot possibly go wrong is that when a thing that cannot possibly
go wrong
goes wrong it usually turns out to be impossible to get at or
repair." -
Douglas Adams
On Sep 16, 2007, at 11:35 PM, Perry The Cynic wrote:
On Sep 16, 2007, at 3:31 PM, Ken Aspeslagh wrote:
Hi:
I'm not sure if this is the right group for this question, but I
can't find
a more suitable group. ;)
We use a very simple installer that uses
AuthorizationExecuteWithPrivileges
to run a tool to do the privileged work.
Our installer is very widely distributed and usually works, but
a very few
customers (2 out of thousands) have a problem:
AuthorizationExecuteWithPrivileges returns errAuthorizationInternal
(-60008).
I've looked at the open sources for the Security and I see that
this err
code is used in dozens of places, most of which I don't yet
understand.
Does anyone have any ideas about what might be wrong on these
few users'
computers? Anything I could ask them or have them try?
Unfortunately I don't have direct access to these machines.
As you've figured out, errAuthorizationInternal means "something
else went
wrong." Something that we didn't specifically expect, and so it
gets lumped
together under that error code. It could be broken or mismatched
system
components (perhaps the result of a misfired software update or
of faulty
hardware). It could be really bizarre permissions on some of the
code
involved. It could be a creatively screwed-up authorization
configuration. It
could be dozens of other things.
Ask your users to reinstall the system (an "archive" type
install) and see if
that fixes the problem. Ask them to create a new (scratch) admin
user and try
the install as that.
Otherwise, without access to the problem system, there's not
terribly much
you can do. You could ask the user to attach gdb to the process,
do a "catch
throw", and pull stack traces of all breaks they get. That may
provide
helpful information when you attach it to your radar (you *do*
have a radar,
yes?), assuming we have very precise and reliable information
about which
versions of the system components are in use there. WIthout that,
it's pretty
useless.
Cheers
-- perry
