Re: exec.basic - comments please

[Mal Lansell <mal@xxxxxxxxxxx>]

Gerry Duprey wrote:

> Howdy,
>
> >     pid=num       //integer identifier (<2^32)
>
> Based on the comments below, any reason the pid has to be a number?
> Since
> it's meant to just be a unique identifier, why not let it be whatever
the
> initiator wants.  If they want a number, great.  If they want to use
the
> name of the program as a pid, great.  They important point, to me, is
> that
> it's some sort of unique identifier with meaning only to the initiator
> and
> as such, the xplExec service shouldn't impose any meaning (even that
> it has
> to be numeric) on it -- just record it and spit it back in
> status/trigger notes.
>
Seems completely reasonable to me - but I'll still include the program
name in the status message too.

> > Program is the name of the executable file to run, without any
path.
>
> Hmmm, I agree about the possibility of running unwanted programs.
> Perhaps
> the xPLExec program could have a series of config items that either
> listed
> all possible executable programs (i.e. if the program is not listed,
it
> can't be run) or something like that.  I suspect being able to run an
> arbitrary program isn't going to be a great thing, and the actual
> number of
> programs to run is probably pretty low.
>
The way I see the security issue is that there are two ways to attack
via xPL.  One is via open ports from the internet, the other is by
installing a rogue application.  I don't think we should concern
ourselves with rogue applications since they can run other programs
directly - they don't need xPL to do it for them!  In any case, an
xPL-specific virus will know where to look for any list of trusted
programs we try to create.

As for the internet attack route - isn't that what the ListenTo
addresses are there to prevent?

8< snip

>
> Hmmm, in the interests of cross platform use of this schema, perhaps
the
> actual error message contents shouldn't be declared here.  Different
O/Ss
> are going to have different failure codes/descriptions and they may
> not be
> mappable (and in the case of a Java version, you'd have to build in
every
> conceivable platforms mappings so it could be cross platform and sort
of
> kills the xplatform idea :-)  Having an error message item is good as
the
> initiator can use it to log a message, display an error, etc.  But
other
> than it being present, implying meaning on it seems problematic to me.
>
I should have made clear that those error values are set by my
Windows-based xPLExec app and not part of the schema - the schema just
includes return= which could be anything at all (it's for the original
sender to interpret according to the system its running on etc).

Mal