Support non-root user installs

[helloworld922]

It would be extremely useful if the ICD loader supported installing OpenCL implementations not as the root user on Unix-like systems.

For example, AMD's APP SDK implementation used to support an environment variable OPENCL_VENDOR_PATH (not sure if they still do?) which could be used to specify what directory to look for ICD files in, defaulting to /etc/OpenCL/vendors if this environment variable is not set.

I'm not sure what the equivalent behavior on Windows might look like.

[kepatil]

Providing an env var as suggested would be analogous to LD_LIBRARY_PATH which is considered a security hole due to the ability of loading arbitrary libraries. Also, we have found no end user installation use cases requiring this feature.

It seems like the feature is being requested mostly for developer convenience. In that case developers can easily add such an env var and rebuild the ICD loader themselves.

[jeffhammond]

The end user installation use case is that I cannot install into /etc without admin privileges, so I am unable to do a userspace installation of OpenCL on many systems. Getting admin on many HPC systems is a huge deal because access to the global filesystem has profound security implications. I am straight up unable to use OpenCL on many systems because of Khronos doesn't value user experience when it comes to their ICD.

And no, it is not acceptable to ask users to patch and build the ICD from source just to be able to use an OpenCL implementation that lives in $HOME.

[keryell]

It seems to me like a good use case too.
That said, if there are other open-source ICD implementations providing this feature, why not just using other ICD?

[helloworld922]

At the time I posted this request, there was only one ICD loader I tested that supported it, and that was the AMD APP SDK 2.8 and older. Anything newer or an ICD loader bundled with another vendor's OpenCL (Intel closed and open source versions, NVidia, POCL, etc.) either used the reference loader or did not support this type of feature. We have since moved away from using OpenCL in our codebase since it just wasn't feasible to get it working on the platforms we were interested in using, so I don't know if the landscape has changed significantly.

[jeffhammond]

@keryell Please think about how an end user behaves. They start with the Linux package manager and only change what is required. Dropping a binary blob into $HOME isn't hard. Please don't ask them to build an ICD from source to use that blob.

[baryluk]

Providing an env var as suggested would be analogous to LD_LIBRARY_PATH which is considered a security hole due to the ability of loading arbitrary libraries.

How is it a security hole and who considers it this way? Application can load arbitrary libraries anyway.

[baryluk]

Never mind, it OCD_ICD_VENDORS was implemented in #77 (it has a bit different semantics that some existing loaders, but it is reasonably close).