嗨，我来帮你梳理下这个权限问题！从你给出的信息来看，不管是一开始的su报错还是后来直接执行脚本的权限拒绝，核心都是权限/SELinux上下文的问题，而且因为SELinux不能关闭，咱们得从合规的角度来解决，一步步来：

先复盘第一个阶段的su: Permission denied问题 #

你一开始用su -c ... - infaap的脚本逻辑，手动以root身份跑没问题，但systemd执行就报错。这是因为systemd的服务进程默认处于受限环境，即使以root启动，su命令可能被SELinux上下文或者systemd自带的ProtectHome、PrivateTmp等安全机制限制。所以你后来改成直接用systemd的User参数切换用户的思路是完全正确的，这才是systemd服务的规范做法！

当前Failed at step EXEC spawning问题的排查方向 #

现在你配置了User=infaap直接执行/infa/pwc/tomcat/bin/infaservice.sh却还是报权限拒绝，大概率是这几个原因，咱们逐个排查：

1. 脚本本身的执行权限不足 #

先确认脚本是否给infaap用户开放了执行权限：

ls -l /infa/pwc/tomcat/bin/infaservice.sh

如果infaap对应的权限位没有x，就执行：

chmod u+x /infa/pwc/tomcat/bin/infaservice.sh

2. 脚本所在目录的权限链不完整 #

Linux权限检查会遍历整个父目录链，infaap用户需要对/infa、/infa/pwc、/infa/pwc/tomcat、/infa/pwc/tomcat/bin每一层目录都有可执行权限（x），才能进入目录找到脚本。
用这个命令查看整个路径的权限链：

namei -l /infa/pwc/tomcat/bin/infaservice.sh

如果某一层目录infaap没有x权限，就用chmod调整，比如：

chmod o+x /infa/pwc/tomcat/bin

（根据实际情况选择调整用户/组/其他用户的权限）

3. SELinux上下文不匹配（关键！） #

这是最可能的原因——即使文件权限正确，SELinux的上下文不对也会被拦截。先检查脚本的SELinux上下文：

ls -Z /infa/pwc/tomcat/bin/infaservice.sh

正常情况下，系统服务类的脚本应该带有system_u:object_r:initrc_exec_t:s0或者system_u:object_r:tomcat_exec_t:s0这类上下文，如果你是手动上传的脚本，大概率是user_u:object_r:default_t:s0这类自定义上下文，systemd会拒绝执行。

解决方法是给脚本设置正确的SELinux上下文：
如果只是单个脚本，执行：

semanage fcontext -a -t initrc_exec_t "/infa/pwc/tomcat/bin/infaservice.sh"
restorecon -v /infa/pwc/tomcat/bin/infaservice.sh

如果整个tomcat bin目录都是自定义路径，更推荐给整个目录设置tomcat专用上下文：

semanage fcontext -a -t tomcat_exec_t "/infa/pwc/tomcat/bin(/.*)?"
restorecon -Rv /infa/pwc/tomcat/bin

4. systemd安全参数的限制 #

systemd默认开启了一些安全参数来限制进程操作，你可以尝试在[Service]段临时添加几个参数放宽限制（注意：尽量先排查完前面的问题再调整，保持安全设置最小化）：

[Service]
# 保留你现有的其他参数，添加以下内容
NoNewPrivileges=no
PrivateTmp=no
ProtectHome=no
ProtectSystem=no

最后验证步骤 #

修改完配置后，先重新加载systemd：

systemctl daemon-reload

然后尝试启动服务：

systemctl start OpenInfa.service

如果还是报错，查看详细日志定位问题：

journalctl -u OpenInfa.service -xe

日志里会给出具体的拒绝原因（比如SELinux的avc: denied记录），再针对性解决即可。

备注：内容来源于stack exchange，提问作者user1765207