Re: Environment/permissions on NSTask-launched app
Re: Environment/permissions on NSTask-launched app
- Subject: Re: Environment/permissions on NSTask-launched app
- From: Brad Peterson <email@hidden>
- Date: Thu, 20 Jul 2006 19:36:01 -0700 (PDT)
> Actually, what you really want the effective *user*
> id. Why do you
> keep using a function that's very clearly documented
> as returning
> something other than what you want?
As I believe I said in my earlier post, I've actually
tried all of the getxxid() functions, all returning
501. I was only including that particular one as an
example. Sorry if that wasn't clearer.
>
> No offense intended, but at this point I agree with
> the others - if
> you're doing this for self-education that's great,
> but if you're
> going to distribute this to other people you
> *seriously* need to turn
> this project over to someone who's more experienced
> with this kind of
> thing. Security issues are not something you want to
> "learn on the job".
Agreed. My goal here is not to understand the finer
points of security issues, I assure you. :)
Rather, I'm interested in figuring out why an app that
uses the Address Book framework is able to write data
when run as a stand-alone app, but not when launched
by an app running as root. (Making matters more
confusing, my helper app that uses Sync Services to
write appointment data works just fine either way.)
You see, this would suggest that the child process is
inheriting something from the parent process even
though as far as security is concerned, this is
expressly not supposed to happen.
All of the diagnostics I can think of - uid functions,
environment variables - yield no visible differences
between running the app stand-alone or as a child
process. Yet, it remains that there most definitely is
a difference.
I'm just trying to figure out what that difference is.
That said, does anyone have any clues on where else I
might look to figure out what's different between
those two environments?
Thanks!
B
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden