Hi Bastian,
On 10 February 2021 at 20:03, Bastian Blank wrote: | Hi Dirk | | On Wed, Feb 10, 2021 at 12:18:04PM -0600, Dirk Eddelbuettel wrote: | > As for your suggested patch to R's own dynload.c: that is very well tested | > and robust system code I do not have any real intention of changing because | > one package out of 17k at CRAN is having hickups under one (maybe suboptimal) | > Debian config. | | I really doubt that. Because the code as it is right now can't be used | in any sensible way without an absolute path. To load anything from | /usr/lib*, which is the primary use of dlopen, you need to hardcode the | path. | | The documentation does not even mention any such specific differences to | how the system loader works on non-Windows.[1] So I doubt this us used | often or at all. | | Also this is the same problem as CVE-2016-1238, see DSA-3628[2]. I | can provide a CVE id for R. Thanks for the CVE. I am happy to discuss this with R Core and one fellow in particular. Before I do so can you clarify what you think the issue is? Loading from user directories as eg ~/R/lib/mypackage/libs/mypack.so ? That is _bread and butter_ for R. Also the `.libPaths()` (for where packages are looked for, leading then for those with native code to loading of their shared libs) never has "." on. Dirk | Regards, | Bastian | | [1]: https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/dyn.load | [2]: https://www.debian.org/security/2016/dsa-3628 | -- | There is a multi-legged creature crawling on your shoulder. | -- Spock, "A Taste of Armageddon", stardate 3193.9 -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
