[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gomd-devel] <SCX> working on Secured Cluster-wide eXecution => help
Re: [gomd-devel] <SCX> working on Secured Cluster-wide eXecution => help!!!
Tue, 9 Sep 2003 22:43:40 -0500 (CDT)
Hiya rejected. I'm fairly neutral w.r.t. "long"? proccesses but i think I
know a simple way yo implement htem if you feel so inclined.
I think that just using a different thread would allow for an elegant
solution. They can pass data back on the heap and are easy to program. (i
recently learned the basics of pthreads (posix threads) in ~30 mins.
I have a good link but its not handy atm.
On Mon, 8 Sep 2003, Gian Paolo Ghilardi wrote:
> Hi all.
> As said yesterday, I'm working on SCX.
> Today I spent 8+ h to find a sceure way to spawn procs.
> Now I've a design problem and I need comments.
> Should we provide support to execute programs exiting in a few millisecs
> (like "ls") or support
> _also_ commands requiring long time before quitting (like "updatedb")?
> I'd like to implement the second type but there could be security holes on
> this approach.
> Moreover I've a problem with the output of these progs.
> We can't make the user to wait for the program output, isn't it?
> My (unsuccessful) attempt:
> I fork gomd to execute program ina separate process.
> I do this so gomd is not forced to waits for program exit.
> But I need the output of teh program.
> The answer should be the pipe.
> So I tried with exec*() family and popen() but, IHMO, the result is not
> I correctly get the process output but I have no idea how to pass it to the
> parent process (the "real" gomd main process) so the parent can't return it
> to the user.
> Any idea?
> I don't want to use shmem or something like that...
> gomd-devel mailing list