On Tue, 25 Sep 2012 11:42:26 -0400, Kent A. Reed wrote:
> 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 :-)
sounds good. I was just trying to be helpful -- sorry if I confused or
offended. I figured that setting a PATH list would be easiest, but I
could be wrong. As for the injection issue, it just occurred to me and
I thought I would mention it. You are correct though, it is simple to
inject stuff in such a case.
EBo --
------------------------------------------------------------------------------
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
