Date: Thu, 31 Oct 2024 02:18:11 -0300 From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= <vini.ipsmaker@gmail.com> To: freebsd-hackers@freebsd.org Subject: [rtld] fdlopen(), fdlputpath() and capsicum Message-ID: <CAK9Rve%2Bn5ey7xq3OUdEY3v8GPXae7=BxeLOqJtumeuLPm%2BH-qQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I'm trying to use capsicum to load untrusted plugins (fdlopen after cap_enter), but I've been facing problems as plugins might depend on not yet loaded libraries (LD_LIBRARY_PATH no longer works after we disable ambient authority). 10 years ago rtld gained the option/env-var to specify directory descriptors to be searched instead[1]. However this env-var is only queried at program startup (the use case is not sandboxing plugins through fdlopen(), but whole programs through exec()). exec() is not an option for my use case. Plugins are meant to load functions that extend the current program image (e.g. manipulating data structures or some shared memory). exec() would just kill any use I have for plugins. My project just stalled on this problem this week. A workaround I've been planning was to statically link the plugins to the libraries (they are untrusted, so this step would occur in a jail), but this won't be an option for every plugin (maybe closed source, maybe licensing problems for the library linked with, ...). I'd like to request a new function to use from C programs: int fdlputpath(int fd); fdlputpath() would just modify the private variable ld_library_dirs introduced in the commit which introduced the env var LD_LIBRARY_PATH_FDS. fdlputpath() would have some restrictions similar to putenv[2][3][4]. The change is simple and it'd open the doors to use fdlopen() for capsicum processes. Thoughts? [1] https://git.quacker.org/d/freebsd-nq/commit/02d3b38e0a766bde374de052a2c= 65a095282f302?style=3Dunified&whitespace=3Dignore-all&show-outdated=3D [2] putenv() modifies a global and it's not thread-safe. fdlputpath() would have the same restriction. [3] It's not safe to deallocate old values inserted by previous calls to putenv() as copies/references to old values might be hanging around. fdlputpath() would have the same restriction. [4] Some implementations of putenv() might provoke intentional leaks to avoid the previous problem. Users of fdlputpath() might adopt a similar approach and keep the passed values hanging around as valid resources forever just in case. --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK9Rve%2Bn5ey7xq3OUdEY3v8GPXae7=BxeLOqJtumeuLPm%2BH-qQ>