[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: exec.basic - comments please
Not sure how concerned we should be, but this does open up the concept of
xPL viruses.
Should there at least be a list of allowed programs that can be executed,
perhaps in an
XML config file?
----- Original Message -----
From: "Mal Lansell" <mal@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Wednesday, October 26, 2005 3:47 PM
Subject: [ukha_xpl] exec.basic - comments please
> Following up the talk of an xPLExec application for launching
> arbitrary executables, I propose the following schema:
>
> xpl-cmnd
> exec.basic
> {
> pid=num //integer identifier (<2^32)
> program="" //executable filename (without path)
> path="" //path to exe (optional)
> path="" //as many as needed
> args="" //program command line argument (optional)
> args="" //as many as needed
> }
>
> xpl-stat
> exec.basic
> {
> pid=num //same integer as sent in the xpl-cmnd
> status=[Failed][Started][Finished]
> return="" //extended info if status is failed or
finished
> }
>
> The pid is a program ID - it is not the same as the Windows Process
> ID, but is a user specified number to enable status messages to be
> associated with commands from xPLHal without having to match the
> entire message body. If only one program is spawned at a time, then
> feel free to just set it to the same value every time if you like.
>
> Program is the name of the executable file to run, without any path.
>
> As many or as few (none is ok) Path and Arg elements can be included
> as needed.
>
> Each Path item must contain only one piece of the path with no / or
> \. These will be inserted by the receiving application.
>
> Each Arg item must contain only one command line argument.
>
> The xPLExec application will attempt to spawn the executable, and
> will respond with a status messages containing either status=failed
> or status=started. If status=failed, then the return item will be
> set to one of the following values:
>
> "argument list too long"
> "invalid argument"
> "program not found"
> "program not executable"
> "out of memory"
>
> If the program runs fine, the an xpl-stat message with
> status=started will be sent. When the spawned program terminates,
> another xpl-stat message will be sent, this time with
> status=finished, and the return item set to the return value from
> the spawned program.
>
> Windows spawn functions also support specifying a set of environment
> variables, but I couldn't see a good way of including those in the
> schema, with all their potential oddball characters. Hopefully that
> will not be too much of a restriction.
>
> Comments would be appreciated.
>
> Mal
>
>
>
>
>
>
>
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe: ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe: ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>
>
>
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.yahoo.com
xPL Main Index |
xPL Thread Index |
xPL Home |
Archives Home
|