Author Topic: 2014 a pain in the...  (Read 15098 times)

0 Members and 1 Guest are viewing this topic.

BlackBox

  • King Gator
  • Posts: 3745
Re: 2014 a pain in the...
« Reply #60 on: April 04, 2013, 03:17:48 PM »
Not sure I understand the problem.  SFSP has always been required for (load ...) if an explicit path isn't provided.  The documentation for the trusted paths makes no mention of modifying any of this behavior, just preventing loading for files which are not in the trusted paths.  These may or may not include the SFSP depending on whether an explicit path is provided for (load ...).  Am I missing something?
^ 1+

Unless I am mistaken, you're rock solid, until this line.

Supplying an explicit path to the Load function has no affect on the mandatory authorization required from TrustedPaths, when SecureLoad > 0.
"How we think determines what we do, and what we do determines what we get."

andrew_nao

  • Swamp Rat
  • Posts: 566
Re: 2014 a pain in the...
« Reply #61 on: April 04, 2013, 03:20:33 PM »
see i understood it as acad now will include subdirectories if the ... was placed for all paths.
now that i changed it around to include all paths in the search file support path and just a ... for the trusted paths it appears to be working.

 

BlackBox

  • King Gator
  • Posts: 3745
Re: 2014 a pain in the...
« Reply #62 on: April 04, 2013, 03:25:40 PM »
see i understood it as acad now will include subdirectories if the ... was placed for all paths.
now that i changed it around to include all paths in the search file support path and just a ... for the trusted paths it appears to be working.

I'm glad you got it sorted (again).

Being able to add "...;" would simplify some of the paths we add to SFSP, but for version, and platform specific SFSP in our Profiles, we'd obviously not use more than a small handful of them. This could be handy though. Neat idea.
"How we think determines what we do, and what we do determines what we get."

ronjonp

  • Needs a day job
  • Posts: 7027
Re: 2014 a pain in the...
« Reply #63 on: April 04, 2013, 03:26:12 PM »
It would be nice if the support paths would include subdirectories.

Windows 10 x64 - AutoCAD /C3D 2020

Custom Build PC

JNieman

  • Water Moccasin
  • Posts: 1655
Re: 2014 a pain in the...
« Reply #64 on: April 04, 2013, 03:28:36 PM »
It would be nice if the support paths would include subdirectories.
I could see that being a boon and a curse depending on where you put your LISP files.  If there is a tremendous amount of subfolders and files in the same location, it could cause long search times when LISP commands are invoked, unless I misunderstand how search paths are accessed and when.

dgorsman

  • Water Moccasin
  • Posts: 2394
Re: 2014 a pain in the...
« Reply #65 on: April 04, 2013, 03:37:37 PM »
Not just LISP - pretty much *everything* in AutoCAD goes through the SFSP to find the first instance of a file.  Thats the reason I put in a wish list item a while back to revamp the SFSP registry storage from a single semi-colon separated string (which has its own issues) and uses separate registry sub-keys for each path, along with a search-depth integer value.  This could now incorporate a trusted path -like boolean flag value as well.  This would allow managed/protected network search folders to be considered "trusted" and local folders to be not trusted and preventing local execution.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

BlackBox

  • King Gator
  • Posts: 3745
Re: 2014 a pain in the...
« Reply #66 on: April 04, 2013, 03:40:23 PM »
Not just LISP - pretty much *everything* in AutoCAD goes through the SFSP to find the first instance of a file.  Thats the reason I put in a wish list item a while back to revamp the SFSP registry storage from a single semi-colon separated string (which has its own issues) and uses separate registry sub-keys for each path, along with a search-depth integer value.  This could now incorporate a trusted path -like boolean flag value as well.  This would allow managed/protected network search folders to be considered "trusted" and local folders to be not trusted and preventing local execution.

I like this idea, a lot.
"How we think determines what we do, and what we do determines what we get."

dgorsman

  • Water Moccasin
  • Posts: 2394
Re: 2014 a pain in the...
« Reply #67 on: April 04, 2013, 04:02:30 PM »
If they wanted to get really clever, they could set the order via a simple list ala the most-recently-used settings elsewhere.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

BlackBox

  • King Gator
  • Posts: 3745
Re: 2014 a pain in the...
« Reply #68 on: April 04, 2013, 05:12:20 PM »
Why would you NOT implicitly trust a path _you've_ added to SFSP?  :?



Were SFSP to be implicitly trusted, you could also simplify the example above, by instead storing each path to a REG_SZ suffixed by it's index, as is done in recent files list.
"How we think determines what we do, and what we do determines what we get."

dgorsman

  • Water Moccasin
  • Posts: 2394
Re: 2014 a pain in the...
« Reply #69 on: April 04, 2013, 05:56:44 PM »
Local application bundles, users trying to override company acaddoc.lsp file using one in the application install folder, and so on.  Don't put too much weight on the "Trusted" moniker, its just a handy reference name.  It could just as easily be "Do no warn when loading files from here", but thats a little Pentagon-ish.    :lol:
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

BlackBox

  • King Gator
  • Posts: 3745
Re: 2014 a pain in the...
« Reply #70 on: April 04, 2013, 06:00:40 PM »
Local application bundles, users trying to override company acaddoc.lsp file using one in the application install folder, and so on.  Don't put too much weight on the "Trusted" moniker, its just a handy reference name.  It could just as easily be "Do no warn when loading files from here", but thats a little Pentagon-ish.    :lol:

Thanks for clarifying, dgorsman... You've always seemed to offer commonsensical advice, which is appreciated.

Cheers
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: 2014 a pain in the...
« Reply #71 on: April 05, 2013, 01:52:25 AM »
Further, while SecureLoad has merit, this illustrates just how poorly thought out TrustedPaths is, as SFSP *should* be the core of what is implicitly trusted from the outset.
Makes the most sense! Both those settings are simply registry entries. So it's not as if someone could add to SFSP but not TrustedPaths - it's not any more secure. As the simplest implementation I'd have said: All folders in SFSP should be implicitly "trusted" and TrustedPaths should only be used to extend explicit path trusting for such stuff as load statements with full paths in their arguments. IMO, that is what adesk should have done if they spent anything more than 2 seconds to plan this thing.
Makes more sense doesn't it? As I understand it's working now (i.e. reading the non-existent documentation): SFSP still operates exactly as before, it's simply a list of paths to search through if no specific folder is specified. Trusted paths is added on top, but is not used as a search list, rather it's only used as a list of paths where loading is allowed. So if a file is in a SFSP but not a TP, then it will be blocked from loading. If the other way round: in TP, but not SFSP, then it won't even be found. Only when the file is in a path listed in both variables will it be loaded.
The ... subfolder for trusted can make it easier, but I can see that such can also defeat the idea behind TP: e.g. if you have something like F:\... in TP, and have your DWG's somewhere on the F drive, then you again have the issue of adadoc.lsp being searched first from the DWG's location. I.e. again infinitely vulnerable to the ACadDoc virus!
I could see that being a boon and a curse depending on where you put your LISP files.  If there is a tremendous amount of subfolders and files in the same location, it could cause long search times when LISP commands are invoked, unless I misunderstand how search paths are accessed and when.
All too true. Just think of how acad slows down when there's just one non-existent path listed in the SFSP. Then place a windows explorer on the root path and type into the search box the word "acaddoc.lsp" ... see how long it takes to find the first of those (if at all). ACad is going to take just as long (at best) for each of the files it would need to find (including all the other auto-loading stuff as well as hatch patterns, etc. etc. etc.). I would steer clear of using such in a search path in this case, acad is slow enough as it is.
If they wanted to get really clever, they could set the order via a simple list ala the most-recently-used settings elsewhere.
Yep, this idea would be a lot more comprehensive without making life more difficult for an admin (at least not by much). Would probably need to have the default for Trusted=True and Depth=1, so it works similar to the old SFSP by default and can be adjusted where needed. But I don't think lots of people would be using the trused=0 idea here, the subfolder depth might be used quite often.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

andrew_nao

  • Swamp Rat
  • Posts: 566
Re: 2014 a pain in the...
« Reply #72 on: April 05, 2013, 01:14:43 PM »
the thought process behind this idea of trusted paths and giving the ability to add to the trusted paths programatically is mind boggling to me if the purpose of this trustedpath is to ensure that only files from these paths are allowed to be used. if you want to test out a lisp file, they inevitablly need to be placed in the path where the program will load from and thus be a trusted file...
which then comes down to, the user inspecting the code to be sure it isnt installing some malware or virus.
so this leaves us where?... right here trying to figure out the reason why this was implimented in the first place.


Jeff H

  • Needs a day job
  • Posts: 6043
Re: 2014 a pain in the...
« Reply #73 on: July 31, 2013, 12:14:57 AM »

CADDOG

  • Newt
  • Posts: 77
  • wishbonesr
Re: 2014 a pain in the...
« Reply #74 on: October 07, 2015, 06:44:08 PM »
Since I'm always at least a year behind any release - it's so cool that everybody else figures stuff out for me.   Thanks guys!!

Code: [Select]
;I don't claim any code.  I probably wrote it.  I probably didn't write it.  I probably wrote it. ...I don't recall.
(defun vl:string->list (str delim / lst loc)
  (while (setq loc (vl-string-search delim str))
    (setq lst (append lst (list (substr str 1 loc)))
  str (substr str (1+ (+ loc (strlen delim)))))
    )
  (append lst (list str))
  )

(defun vl:list->string (delim ls / out)
  (setq out (apply 'strcat (mapcar (function (lambda (x) (strcat x delim))) ls)))
  (if out (vl-string-right-trim delim out) "")
  );defun list->string

;it doesn't hurt to add the same path multiple times.  Autocad takes care of duplicates
;as well as the adding a single ";<path>".
;Ex. (AddTrustedPath "c:\\temp")
(defun AddTrustedPath (addpath / )
  (setvar 'trustedpaths (strcat (getvar 'trustedpaths) ";" addpath))  
  );defun AddTrustedPath

;Ex. (RemoveTrustedPath "c:\\temp")
(defun RemoveTrustedPath (rpath / )
  (setvar 'trustedpaths
  (vl:list->string ";"
    (vl-remove-if (function (lambda (path)
    (eq (strcase path) (strcase rpath))
    ));function
      (vl:string->list (getvar 'trustedpaths) ";")
      );vl-remove-if
    );vl:list->string
  );setvar
  );defun RemoveTrustedPath

;Ex. (loadTrustedPaths "P:\\AutoCAD2014\\CompanySupportPaths.txt")
;file content should include use regular path separators (not list "\\" type)
;keep the file clean and accurate - no checking.
(defun loadTrustedPaths (srcfile / sf cLine)
  (if (setq sf (open srcfile "r"))
    (progn
      (while (setq cLine (read-line sf))
(if (and
      (> (strlen cLine) 2)
      (/= "" (setq cLine (vl-string-left-trim " " (vl-string-right-trim " " cLine)))))
  (AddTrustedPath cLine)
  );if line has content
);while
      (close sf nil)
      );progn
    (princ (strcat "\n File could not be opened: " srcfile))
    );if file open
  );defun loadTrustedPaths