Setting capability on the script will not be effective. It's the similar situation as not working setuid bit on script. Similar as in the latter case it's the implementation of how execve handles shebang and the security reasoning behind it (for details see: Allow setuid on shell scripts).
I think you have these options
set the capabilities on interpreter itself (actually rather a copy of it)
- you have a problem here that anybody who is able to execute it will run with those elevated capabilities (be able to execute some arbitrary script or start it interactively)
write a wrapper executable which will have a hardcoded logic to execute your script, and set desired capabilities on this executable
- make sure that nobody is able to modify nor remove / replace the script
- still by doing
chroot one might missuse such wrapper
In both cases you would have to make sure capabilities set will survive execve by setting inheritable flag. You might also use pam_cap distributed with libcap usually, to actually activate desired capabilities by configuration only for selected users.
And in general you want to make sure nobody is able to modify behavior of your interpreter by changing environment eg. PYTHON_PATH or something similar.
