WrapEarnPass left a comment (geany/geany#4590) Sure. I am a confined user on a SELinux system. I wanted to test changes for a plugin. I compiled it, and put it in the ~/.config directory that was suggested:
<img width="699" height="275" alt="Image" src="https://github.com/user-attachments/assets/96d1b329-e500-4929-9a14-e36faf6005fe"; /> https://plugins.geany.org/pynav.html links to https://www.geany.org/manual/current/index.html#plugins which seemed to confirm ~/.config as a more ?importanter? path than the one in preferences. Loading geany afterward triggered an AVC deny because dlopen opens the files with ```mmap(...PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE...)```. PROT_EXEC, even though it is a memory flag is regarded by SELinux as a execute permission. ~/.config, per the xdg standard is mapped to SELinux xdg_config_t (read/write/no-execute). SELinux has mappings for user executables (read/write/map/execute) defined for ~/bin (even though that is a convention, not an actual standard) as user_bin_t, ~/.local/bin per the xdg standard also as user_bin_t, and then entire rest of ~/.local as xdg_data_t. I eventually worked around it by putting them in ~/bin, and putting a symlink from ~/bin to ~/.config. I did this before I found the bit in the geany docs that suggested symlinking. As geany's plugin search path is by default attempting to do something it shouldn't, it seemed reasonable to ensure this wasn't an issue for anyone else going forward by aligning geany's implementation more closely with xdg, which allows it to automatically align with anyone who consumes xdg, like SELinux. I'm a little surprised this hasn't already been an issue with Ubuntu's AppArmor profiles, but then I see no one has gotten around to writing a profile for geany yet. As you noted, it has nothing to do with the DAC permission bits. I discussed that in #1566, because in addition to the MAC permissions(SELinux), the Makefile is apparently dropping the .so's as 755, even when the system umask is more restrictive, and I was taught not to grant +x to anything that doesn't absolutely require it. So, .so's shouldn't be ugo+x on most *nix's. I didn't notice this earlier as I was building my local plugins with cmake+clang initially and clang appears to honor umask. I have geany@master checked out and building with autogen now, I can submit a patch to address this if you'd like. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/4590#issuecomment-4737428580 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/4590/[email protected]>
