On 9/25/2012 10:12 AM, EBo wrote:
> On Tue, 25 Sep 2012 09:57:54 -0400, Kent A. Reed wrote:
>> On 9/25/2012 9:11 AM, Sebastian Kuzminsky wrote:
>>> On 09/25/2012 06:42 AM, Gene Heskett wrote:
>>>> Am 25.09.2012 um 04:09 schrieb Gene Heskett:
>>>>>> Actually, there might be a second way too. If we record the
>>>>>> directory
>>>>>> path at open time, and then just assume the subroutine is in the
>>>>>> same
>>>>>> dir as the top level source gcode is.
>>>>>>
>>> I too sometimes use project-specific subroutines, and like you I'm
>>> not
>>> totally thrilled to put them in a central place where
>>> [RS274NGC]SUBROUTINE_PATH can see them.
>>>
>>> I think this second option seems like a good idea. Maybe we could
>>> have
>>> two different CALL functions, like how C has two different #include
>>> syntaxes: one for searching the system-wide place only, and another
>>> for
>>> searching first the current directory then the system-wide place.
>>>
>>> By "the current directory" I mean the directory of the file running
>>> CALL, and by "the system-wide place" i mean the SUBROUTINE_PATH.
>>>
>>>
>> I like your analogy to C as a way of illustrating your suggestion but
>> perhaps we could just change the behavior of the current syntax to
>> search first the current directory and then the system-wide place. Is
>> there really a use case that calls for a variant syntax to bypass the
>> current directory?
> Assuming that you are talking about a PATH list (similar to how most
> *NIX shells deal with ${PATH}) then I would suggest not setting the
> current directory as the default first choice. Sometimes you want to
> explicitly overload something and you need to make sure that you can put
> it before the system one. Also, assuming "." or current directory, have
> been used in the past to inject trojans and viruses on *NIX machines. I
> think we should think twice about allowing that if a rogue subroutine
> could be injected...
>
> just my 0.2875 (accounting for inflation).
>
> EBo --
>
Hi, EBo.
It isn't clear to me how my proposal is any more insecure that the
current situation is. What make the *NIX approach more secure is the
placement of certain default *executables* in protected system
directories, and then it only works if the environmental PATH variable
is correct (and the executable name hasn't been aliased, etc.). The
current LinuxCNC behavior is to look for all G-code subroutines in a
single place (perhaps default, perhaps defined by SUBROUTINE_PATH) but
it's an ordinary directory. Inject away.
I like Gene's second approach because it doesn't require the author of a
G-code routine to know anything about the directory structure the code
may end up in; e.g., the combination of a routine and its supporting
subroutines is portable. The only thing I didn't like about Sebastian's
modification is the addition of yet another variant syntax into our
variant of RS274/NGC. The notion of rolling over from the current
directory to the system-defined directory is fine with me.
One can find Occam's Razor stated in many different forms*. I am fond of
"entities should not multiply without necessity" which in this case
means "no new variant syntax without necessity." In this spirit of this
heuristic, I accept that, if the necessity exists, then we should go
forth and multiply :-)
Regards,
Kent
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
