A simple reproducer for this is:

# qemu-img create -f vmdk test.vmdk 10M
# nbdkit -fv vddk libdir=/root/vddk_libdir/vddklib_1 file=test.vmdk

where /root/vddk_libdir/vddklib_1 points to VDDK 6.5.

It fails with:

nbdkit: error: /root/vddk_libdir/vddklib_1/lib64/libvixDiskLib.so.7: cannot open shared object file: No such file or directory

(The error message is a bit inaccurate.  What it means is it tried to
load libvixDiskLib.so.7 and then libvixDiskLib.so.6, and both failed,
but it only printed libvixDiskLib.so.7 in the error message)

The real reason for the failure is an SELinux policy decision:

  time->Tue Mar 15 07:51:56 2022
  type=PROCTITLE msg=audit(1647345116.291:4113): proctitle=6E62646B6974002D66760
07664646B006C69626469723D2F726F6F742F7664646B5F6C69626469722F7664646B6C69625F310
066696C653D746573742E766D646B
  type=SYSCALL msg=audit(1647345116.291:4113): arch=c000003e syscall=10 success=
no exit=-13 a0=7ffd79c29000 a1=1000 a2=1000007 a3=7f1bcc2ab000 items=0
ppid=121095 pid=122597 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=pts2 ses=8 comm="nbdkit" exe="/usr/sbin/nbdkit"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
  type=AVC msg=audit(1647345116.291:4113): avc:  denied  { execstack } for  pid=
122597 comm="nbdkit"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
permissive=0

audit2allow suggests:

  #!!!! This avc can be allowed using the boolean 'selinuxuser_execstack'       
  allow unconfined_t self:process execstack;

Enabling that boolean fixes the problem.

However the boolean seems to have changed in RHEL 9.0 very recently, and it
will undoubtedly break many other things, so this seems wrong.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=2013629

See also bug 2055822 which seems to be the root cause.

I'm setting this bug as a blocker because the default has clearly
changed to prevent executable stacks.  I just installed a fresh RHEL 9
from Beaker (RHEL-9.0.0-20220318.d.0), then I installed VDDK 6.7.0
and nbdkit, then I ran:

$ qemu-img create test.vmdk -f vmdk 100M
$ nbdkit vddk libdir=~/vddk-6.7.0/vmware-vix-disklib-distrib file=test.vmdk --run 'nbdinfo $uri'

which failed with the characteristic problem with executable stacks.
With later versions of VDDK (which do not have executable stack) this works.

This is an unannounced ABI change.

Created attachment 1866564 [details]
SELinux booleans after fresh RHEL 9 install (getsebool -a)

The execstack permission is required when a process calls the mprotect syscall
on the stack to mark it executable. Such a permission should usually not be
needed as it is a potential security problem, so there are, in general, good
reasons to have it disabled by default. Request for it may indicate a security
issue with the package or library code.

BZ#2055822, cloned from RHEL 8 BZ#2053815, was accepted by SELinux team and the
fix delivered as a part of the latest RHEL 9 selinux-policy build to improve
default security footprint of a fresh RHEL system.
The build exists since 2022-02-24, verified 2022-02-28, that is in time for RHEL 9.0 GA.
Surely it was quite late in the RHEL 9 development stage, but evaluated as so
important thas it was accepted rather for 9.0 GA, than make such a change during
prodcution phase. The only reason is that the initial bug was reported not long ago.

The change was actually a revert of a 2012 dist-git commit which changed the git
default for selinuxuser_execmod and selinuxuser_execstack without any rationale.
Our testing suite covers known scenarios with Red Hat provided software, so the
change passed testing (see #c9) without noticing a problem. It turned out that
there are scenarios which depend on the permission for user executed commands,
therefore the change introduced in bz#2055822 will now be partially reverted,
still leaving the administrators the option to disable related booleans.

Awareness of the impact of the change is one of the outcomes, surely we are
sorry for any inconvinience it may have caused.
BZ#2013629 may look similar, but different and will be closed wontfix.

*** Bug 2068609 has been marked as a duplicate of this bug. ***

*** Bug 2067494 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: selinux-policy), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3918