Re: Troublesome app when scaling it up, how to proceed?
Re: Troublesome app when scaling it up, how to proceed?
- Subject: Re: Troublesome app when scaling it up, how to proceed?
- From: "Gerben Wierda" <email@hidden>
- Date: Thu, 25 Oct 2007 16:32:51 +0200 (CEST)
- Importance: Normal
> On 25 Oct 2007, at 07:39, Gerben Wierda wrote:
>
>> For one, my subprocess sometimes have to run in admin mode and I am
>> using
>> AuthExecuteWithPrivileges() for that. That function is really broken,
>> because for processes started like that you cannot get the PID, you
>> cannote get stderr seperately from stdout (it uses a bidirectional
>> buffered pipe), you cannot pass an environment. So subprocesses
>> like these
>> go via a different route. The main program creates named pipes for
>> stdin,
>> stdout and stderr, passing the environment and pid, then starts a
>> generic
>> subprocess. This subprocess attaches stdout, stdin and stderr to
>> the right
>> named pipes, communicates the pid back, then execs the actual
>> subprocess
>> that needs to be run. Reading output from the stderr and stdout named
>> pipes is done in separate threads of the main program. These programs
>> communicate to the main thread using DO. Since the PID has been
>> communicated back, I can kill these subprocesses from within the main
>> program (which otherwise would have been troublesome as one does
>> not know
>> the pid).
>
> On 25 Oct 2007, at 07:44, Gerben Wierda wrote:
>
>> I agree, but the md5 example was just an example. I use several other
>> programs as well and there is not such a library/possibility for all.
>> Secondly, as some of these processes have to run with privileges, I
>> need
>> to use AuthExecuteWithPrivileges() if I do not want to turn my
>> entire app
>> into a privileged operation (and I don't as I follow the principle
>> that
>> privileged operations should be kept to an absolute minimum).
>
> From reading this thread, it sounds like you may have adopted a
> somewhat baroque solution to whatever problem you're actually trying
> to solve.
>
> Perhaps a simpler mechanism would be to use AuthExecuteWithPrivileges
> () *once* to set the setuid bit on a helper tool that you then
> execute in the normal UNIX manner (i.e. fork()/exec() or similar)?
That is a logical solution and it is in fact the preferred solution.
However it is only safe if the helper tool is a specific tool doing a
specific task. That is not the case here, as this system can startup *any*
tool with admin privileges (think the same way that Installer.app runs a
post or preflight script with admin privileges). Currently, Ápple's
installer warns you about 'running a program' with privileges, do you
agree? If you say yes, the post/pre script is run as admin. If that script
creates a trojan somewhere, you have a security breach. I do not know how
Apple has fixed that potential problem currently, so I do not know if it
is possible to make a doctored .pkg with a doctored preflight that sets up
a setuid sh or anything like that. Anyway, my system is like that in that
the functionality that is being run as admin is not fully defined in
advance (hence there are all kinds of checks with gpg/openssl to make sure
nobody has doctored with the actual program that is being run).
> Once the tool is setuid root, you don't need to use
> AuthExecuteWithPrivileges() again, even if you need to pass an
> authorisation context to it. That would mean you could avoid using
> DO, that you can set-up your sub-processes' file handles as you
> require, and that you can get their pids as usual for a UNIX program.
A previous version worked a bit like this a few years ago, but I moved
away from that approach to AEWP() because that approach made me run a lot
of stuff with privileges (because it is all generics) which is not
necessary. So, when I created this, I chose this setup to minimize the
amount of stuff that runs with privileges to an absolute minimum.
> As for the problem of running out of resources, it's hard without
> actually seeing what your program is doing to know why (or indeed
> whether) that's happening. My guess is that the apparent complexity
> isn't helping any, though.
I agree fully. It has all become too complex. I am thinking also about
dropping everything and starting from scratch, but that requires a usable
solution for my functional demands or strongly minimizing the functional
setup.
G
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden