Rustc: error while loading shared libraries: libLLVM-15-rust-1.66.0-stable.so

English Programming/Scripting
#1

Hi, I’ve succeeded to mess up my rust installation and have no idea how to solve it. I’ve tried to install it with both the methods from Rust - openSUSE Wiki (but with transactional-update pkg install rustup instead of zypper due to MicroOS). The issue is still the same. This is how it looks when I try to update as user:
~> rustup update
info: syncing channel updates for ‘stable-x86_64-unknown-linux-gnu’
info: checking for self-updates

stable-x86_64-unknown-linux-gnu unchanged - (error reading rustc version)

info: cleaning up downloads & tmp directories
~> rustc -v
/home/freefox/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc: error while loading shared libraries: libLLVM-15-rust-1.66.0-stable.so: cannot enable executable stack as shared object requires: Permission denied

Two questions:

  1. Any idea of how to solve the above issue? Where should libLLVM-15… be located?
  2. What is the “correct” way to install rust in MicroOS?
    • I guess the idea with MicroOS is to run containers, so I should have a separate container with my developer environment?
    • Or should rust be installed from within VSCodium, that is the IDE/container where I develop the rust code?
    • Or should rust be installed as user as it is only a one user environment today and then connected to from VSCodium somehow.

In my case it maybe isn’t that important, but it would be interesting to get an idea of when to use which installation approach.

#2

@freefox if want systemwide, then pop into a transactional-update shell do whatever, then exit and reboot…

Container, or use distrobox (the default) or prior to that toolbox, or flatpak VSCodium.

#3

Are you using SELinux?

#4

Yes. Nothing I have added. I suspect it is the default in MicroOS?

localhost:~ # sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33

Do I need to tweak SELinux settings?

I tried distrobox with leap after @malcolmlewis answer. Within the distrobox leap, after installing gcc and rust again, it works. But it is a bit … slow. I make updates in the flatpak VSCodium, save, switch to the terminal with leap, compile with cargo build. And sometimes the changes isn’t reflected, then when I try again they are, so there are some caching somewhere i guess?

I’m still confused about best way of setting up the environment…
Maybe it would be better to install VSCodium within my leap to get them to work better together?

#5

Does it work after setenforce 0?

#6

Thanks! Works.
So have I opened up my entire system to the world now? :smiley:
I guess the correct solution would be to update the policies. At least I suspect that I need to update some config file somewhere to make the change permanent? (mark in output below.)

I add some more here to remember better next time I get around. 3 different SELinux modes:
1. Enforced : Actions contrary to the policy are blocked and a corresponding event is logged in the audit log.
2. Permissive : Permissive mode loads the SELinux software, but doesn’t enforce the rules, only logging is performed.
3. Disabled : The SELinux is disabled entirely.
setenforce 0 changes from enforced to permissive. Looks like this with sestatus.
localhost:~ # sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33

#7

You were not even aware that you were using SELinux and SELinux is not used (by default) on Leap or Tumbleweed and the world still goes on.

Anyway, it seems to be recent change in upstream SELinux defaults. RH apparently reverted it ( 2064274 – selinux-policy default has changed to disallow executable stacks by default (redhat.com)), and you can allow executable stack (thus reverting to previous default) with setsebool -P selinuxuser_execstack on. Also, you should open bug report so SUSE can relax default policy as advised by The Adaptable Linux Platform Guide. Sorry, I mixed different topics (MicroOS is not - yet - ALP). But you still should open bug report :slight_smile:

Alternative is to check every application/library that exhibits this problem whether it really needs executable stack and if not, disable it using execstack command and file bug report against each application to build with -z noexecstack. And if application really needs it - extend SELinux policy to allow executable stack for this specific binary.

1 Like
#8

Thanks. Reassuring to hear that the system is still (fairly) secure.

This is too far from my comfort zone to file a bug report. I have no clue what I’m talking about and will not be of any use if there are questions. If you still want me to do it I will need a link to where to file the bug report.