The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[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

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.