I can repro this in a GN/component build. This is an interesting bug and is related to component build, rpath and runpath.

In non-component build, our adapter uses "//build/config/gcc:rpath_for_built_shared_libraries", which will set a RUNPATH to $ORIGIN/. [1,2] This is how the CDM adapters find the CDM in the same folder on Linux.

In component build (not shipped in production, but is used in dev and test), the adapter doesn't use "//build/config/gcc:rpath_for_built_shared_libraries" and hence has no RUNPATH set. So if you ldd you'll see:

ldd libclearkeycdmadapter.so
        libclearkeycdm.so => not found

Even though libclearkeycdm.so is in the same folder. Note that unlike Windows, Linux doesn't search for the current folder for libraries.

The questions is how does the tests work before without my change. It turns out that on component build, all executables have a RPATH set to the ORIGIN [3]. Note the --disable-new-dtags flag [4], which will make a RPATH instead of a RUNPATH. Also, note that RPATH is transitive [6,7] (while RUNPATH is NOT).

So without my change, the cdm adapter and the cdm are both in the output folder, same as browser_tests. 
Because brwoser_tests has a RPATH pointing to the output folder (ORIGIN), and because RPATH is transitive (browser_tests -> adapter -> cdm), the dynamic linker can find the CDM.

Now with my change, the adapter and the CDM are in a new ClearKeyCdm folder. The CDM is dynamically opened (e.g. dlopen), so there's no path issue. But since the adapter doesn't have a RUNPATH or RPATH, and the CDM is not in browser_tests' RPATH (ORIGIN), the CDM cannot be found, causing the error.

One thing that I don't understand is that why the error is "Operation not permitted" instead of "file not found".

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=583009#c27
[2] https://code.google.com/p/chromium/codesearch#chromium/src/media/cdm/ppapi/ppapi_cdm_adapter.gni&l=62
[3] https://code.google.com/p/chromium/codesearch#chromium/src/build/config/gcc/BUILD.gn&l=81
[4] https://code.google.com/p/chromium/codesearch#chromium/src/build/config/gcc/BUILD.gn&l=101
[5] https://bugs.chromium.org/p/chromium/issues/detail?id=583009#c30
[6] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638
[7] http://jorgen.tjer.no/post/2014/05/20/dt-rpath-ld-and-at-rpath-dyld/

Given the fact that the CDM and the CDM adapter can be in any folder, e.g. when they are component updated, they can be under USER_DATA_DIR, we shouldn't assume that the loader will always know where to find the CDM (with a correct RPATH). The only assumption we can have is that the CDM and the adapter are always in the same path, and for the adapter to find the CDM, the adapter should always have a RUNPATH, even in component builds.

So It seems to me the easiest fix is to remove the condition "!is_component_build" so that we'll always set a RUNPATH in the adapter. This will only affect component build, which won't affect production.

https://code.google.com/p/chromium/codesearch#chromium/src/media/cdm/ppapi/ppapi_cdm_adapter.gni&l=62

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91b24b67d6ac964927c3a008fc16b2c9a068f7f7

commit 91b24b67d6ac964927c3a008fc16b2c9a068f7f7
Author: xhwang <xhwang@chromium.org>
Date: Tue May 17 23:57:28 2016

media: Set RUNPATH in cdm adapter in GN component build

The CDM should always be able to find the CDM, regardless of how the
loader of the CDM adapter is configured.

In tests, currently, browser_tests sets a RPATH of $ORIGIN, which
makes the test work. But if we put the CDM adapter and CDM in a
different folder, then the test will break in GN component build.

See BUG for more detailed discussion.

BUG= 612007 
TEST=browser_tests pass in GN component build

Review-Url: https://codereview.chromium.org/1981723002
Cr-Commit-Position: refs/heads/master@{#394272}

[modify] https://crrev.com/91b24b67d6ac964927c3a008fc16b2c9a068f7f7/media/cdm/ppapi/ppapi_cdm_adapter.gni