Will `semanage fcontext` and `restorecon` safe to run when SELinux Disabled? (During Atomic custom image build and others)

Ask Fedora
,
1

Cross post from: Help to verify this SELinux related scripts on atomic systems (chcon, bin_t) - General - Universal Blue

Just see the result, I need to run

semanage fcontext -a -t bin_t "/usr/lib/rustdesk/rustdesk" 
restorecon -v "/usr/lib/rustdesk/rustdesk"

In the rpm spec file, but, the AI continuously said I should check SELinux status before running semanage and restorecon command, because it may fail, but from my testing(On ublue/kinoite custom image), it is not

bash-5.2# semanage fcontext -a -t bin_t "/usr/lib/rustdesk/rustdesk"
libsemanage.semanage_rename: WARNING: rename(/etc/selinux/targeted/active, /etc/selinux/targeted/previous) failed: Invalid cross-device link, fall back to non-atomic semanage_copy_dir_flags()
bash-5.2# echo $?
0
bash-5.2# restorecon -v "/usr/lib/rustdesk/rustdesk"
bash-5.2# echo $?
0

If I added conditional expressions (if) in the script, it means it will never run on the Atomic image builds, but I can’t sure if it is only not failed on Fedora, or it is really a potential that running semanage and restorecon may failed? If so, what should I do? Making it fail open?

3

Reading refact: linux, chcon, bin_t by fufesou · Pull Request #10293 · rustdesk/rustdesk · GitHub, you should remove all the manual SELinux logic and move your binary to /usr/bin and that will let RPM/dnf/rpm-ostree install it using the right default context for applications (bin_t).

If you don’t want it to be visible in the path, then it should be under /usr/libexec/.

2 Likes
4

/usr/bin/rustdesk is linking to /usr/lib/rustdesk/rustdesk because it needs some externel assets(On /usr/lib/rustdesk/ folder)

bash-5.2# pwd
/usr/bin
bash-5.2# ls -l | grep rustdesk
lrwxrwxrwx   1 root root           26 Dec 16 15:19 rustdesk -> /usr/lib/rustdesk/rustdesk

In this case, what is the proper way to do if this is not single binary? (Or I should call them to join this discussion, or give advice directly in their PR cause I’m not the devs)

5

If you don’t it to be visible in the path, then it should be under /usr/libexec/.

rustdesk needs to be in the path for some unattended configs.

6

Looking at how VSCodium is packaging things, they put everything in /usr/share/codium: Releases · VSCodium/vscodium · GitHub

2 Likes
7

Thanks, I’ll let them know.

8

Will it be able to inherit SELinux tag if moved to /usr/share/?

Because…well…

xlion@fedora:~$ stat -c "%C" /usr/bin/rustdesk
unconfined_u:object_r:bin_t:s0
xlion@fedora:~$ stat -c "%C" /usr/lib/rustdesk/rustdesk
system_u:object_r:lib_t:s0

/usr/bin/rustdesk is linking to /usr/lib/rustdesk/rustdesk because it needs some externel assets(On /usr/lib/rustdesk/ folder)

bash-5.2# pwd
/usr/bin
bash-5.2# ls -l | grep rustdesk
lrwxrwxrwx   1 root root           26 Dec 16 15:19 rustdesk -> /usr/lib/rustdesk/rustdesk
9

I would recommend giving this a try (moving everything to /usr/share/rustdeck + symlink to it in /usr/bin/) to see if this works.

1 Like
10

Hi, they decided to put in /usr/local/rustdesk They now decided to put in /usr/share, but I’m curious is this a bug or user fault?

But I’m having problem that the /usr/local/rustdesk folder never exists after custom image build, also rpm-ostree layering, is this correct procedure to make correct symlink?

mkdir -p "/var/usrlocal" && ln -s "/var/usrlocal" "/usr/local"

Solved: refact: linux, move rustdesk into /usr/share by fufesou · Pull Request #10327 · rustdesk/rustdesk · GitHub

11

/usr/local is a symlink to ../var/usrlocal which is local state that you can not and should not touch during the image build/derivation steps.

1 Like