On Tue, Dec 20, 2022 at 02:01:03PM +0000, indivC wrote: > Crystal, > > I really appreciate the detailed explanations > and step by step instructions. > I was able to follow everything without a problem > and was able to finally access the python file from a web browser.
Glad you've got it working! > On Monday, December 19th, 2022 at 11:07 AM, Crystal Kolipe > <kolip...@exoticsilicon.com> wrote: > > > # mkdir /var/www/usr/local/lib/pyton3.9 > > # mkdir /var/www/usr/local/include/pyton3.9 > > A slight correction to the lines above > in case anyone comes across this in the future. > The above lines should be: > mkdir -p /var/www/usr/local/lib/python3.9 > mkdir -p /var/www/usr/local/include/python3.9 Yes, you're right, you need to make the intermediate directories too. > > The /var/www/usr/local/lib path is not being searched for dynamic > > libraries when you try to run the python interpreter within the > > chroot. The easiest way to 'make it work' is to move the files > > you just copied to /var/www/usr/local/lib/ to /var/www/usr/lib/ > > instead. > > I think the first sentence makes sense to me. > While trying to search for a solution to the 'ld.so' error, > a lot of the solutions recommended two possible solutions. > The first was to add '/var/www/usr/local/lib' > to the library search path with > 'export LD_LIBRARY_PATH=/usr/lib:/var/www/usr/local/lib'. > The second was to attempt the same thing with > 'ldconfig /var/www/usr/local/lib'. > Neither of these seemed to work, so not sure why. It doesn't make any sense to add a path beginning with /var/www to the library search path from outside the chroot. By doing that, instead of allowing programs within the chroot to search the additional directory or directories, you are telling programs outside the chroot that they can do so. Obviously you will never have a program running outside the chroot that needs to load libraries from /var/www/...anything... Within the chroot, the path would be /usr/local/lib anyway, without the leading /var/www, and if you want to add that path to the library search path within the chroot, then you can run lconfig from within the chroot: # mkdir /var/www/sbin # mkdir -p /var/www/var/run # cp /sbin/ldconfig /var/www/sbin/ # chroot /var/www # sbin/ldconfig /usr/local/lib All this is doing is creating a /var/www/var/run/ld.so.hints file. > Also, I don't really understand why your solution worked. Because /usr/lib is always searched, unless you take specific steps to exclude it. On a normal system with hundreds or thousands of libraries, you probably wouldn't want everything in one directory. But a chroot environment is intended to be minimalist anyway, so it's really a matter of personal preference whether you create a /usr/local/lib directory for non-system libraries or not. > I understand why putting python(1) in chroot is a bad idea. > Therefore, what are the other possible options? Use FastCGI :-) This changes everything. Your python program now runs continuously instead of being launched repeatedly by the webserver for each incoming request. It communicates with the webserver using a socket, (usually a local socket), using the FastCGI protocol. This means that your program does not need to, (and should not), run within the webserver's chroot. It might run in it's own chroot, and it might also use other security features of OpenBSD such as unveil and pledge. It can do this _entirely separately_ from anything that httpd does. In this way, if your program is compromised, it does not have direct access to the memory space of the webserver, so it cannot change the contents of variables, run arbitrary code in the scope of httpd, etc, etc. It's also usually better for performance. Consider, for example, if your program reads a large database when it starts. The way you have things set up at the moment, it's going to be doing that read for every single request. With a single long-running invocation, which is what you usually have when using FastCGI, the database only needs to be read once. And of course you don't have the complicated set up of the chroot to deal with.
