[SERVER-9426] Develop support library for searching well known filesystem locations for module implementations Created: 23/Apr/13 Updated: 26/Oct/21 Resolved: 26/Oct/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
We will need a concept of a search path for modules. At the very least, when asked to load a module with no explicit path information, this system should search at least:
After searching these locations, the unqualified name should be attempted to fall back to LD_LIBRARY_PATH or the equivalent. |
| Comments |
| Comment by Tad Marshall [ 23/Apr/13 ] |
|
You should consider the security implications of loading executable code from the current working directory. We have a "cd()" function in JavaScript that can change the CWD, so at least for the shell this may not be fully under the administrator's control. Windows includes the CWD in the module search path by default, but added a feature to disable this due to the use of this by exploits. http://support.microsoft.com/kb/2264107 Another possibility is to require a digital signature on anything loaded at runtime. In Windows, you would need to load the library as a datafile (LOAD_LIBRARY_AS_DATAFILE) to check for a digital signature in order to prevent DllMain() from running on load. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx |