Bug in `less` and `lessopen.sh`

English Applications
1

I recently did a long-procrastinated zypper dist-upgradeof Slowroll and now have a bug in the less utility that wasn’t there before. See below for version information.

The bug:

$ less some_file
Failed to execute target.: Permission denied

The file “lesses” correctly but gives the minor yet annoying error message on exit. Either of the following two workarounds eliminates the error message:

$ less --no-lessopen some_file

or

$ unset LESSOPEN
$ less some_file

Neither of these solutions are optimal because the purpose of /usr/bin/lessopen.sh is to preprocess various non-ascii files and extract their text data for viewing. For example:

$ less some_file.pdf

Without either of the above workarounds this “lesses” any text in the PDF, but gives the error on exit. With either workaround enabled, less gives a warning and exits immediately if answered “n”, or displays the raw PDF bytes if “y”. For example:

$ less --no-lessopen some_file.pdf
“some_file.pdf” may be a binary file. See it anyway?

I believe the problem is in the /usr/bin/less binary itself, not the /usr/bin/lessopen.sh helper script because if the latter is copied, unchanged, into any directory earlier in $PATH than /usr/bin and /bin, thenless works perfectly on all file types, without the annoying error.

Can anyone reproduce this problem? Should I try to report it in bugzilla? My system is:

$ cat /etc/os-release
NAME=“openSUSE Tumbleweed-Slowroll”
# VERSION=“20260707”
ID=“opensuse-slowroll”
ID_LIKE=“opensuse-tumbleweed opensuse suse”
VERSION_ID=“20260707”
PRETTY_NAME=“openSUSE Tumbleweed-Slowroll”
ANSI_COLOR=“0;32”
# CPE 2.3 format, boo#1217921
CPE_NAME=“cpe:2.3:o:opensuse:slowroll:20260707:::::::*”
#CPE 2.2 format
#CPE_NAME=“cpe:/o:opensuse:slowroll:20260707”
BUG_REPORT_URL=“https://bugzilla.opensuse.org”
SUPPORT_URL=“https://bugs.opensuse.org”
HOME_URL=“https://www.opensuse.org”
DOCUMENTATION_URL=“https://en.opensuse.org/openSUSE:Slowroll”
LOGO=“distributor-logo-Slowroll”

$ uname -a
Linux redacted-host-name 7.1.5-1.0.10.sr20260707-default #1 SMP PREEMPT_DYNAMIC Tue Jul 28 09:31:57 UTC 2026 (862e13e) x86_64 x86_64 x86_64 GNU/Linux

$ less --version
less 704 (POSIX regular expressions)
Copyright (C) 1984-2026 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Home page: https://greenwoodsoftware.com/less

$ zypper search --provides --installed-only --verbose =less
Loading repository data…
Reading installed packages…

S | Name | Type | Version | Arch | Repository
—±-----±--------±-----------±-------±----------
i+ | dssi | package | 1.1.1-14.5 | x86_64 | repo-oss
filelist: /usr/bin/less_trivial_synth
i | less | package | 704-1.2 | x86_64 | repo-oss
filelist: /usr/bin/less
filelist: /usr/bin/lessclose.sh
filelist: /usr/bin/lesskey
filelist: /usr/bin/lessopen.sh
provides: /usr/bin/less

$ zypper repos --uri | grep -E ‘repo-oss.*Yes’
5 | openSUSE:repo-oss | repo-oss | Yes | (r ) Yes | Yes | http://download.opensuse.org/slowroll/repo/oss

2

less works for me on Tumbleweed

> which less
/usr/bin/less
> ls -als /usr/bin/less
276 -rwxr-xr-x 1 root root 279904 Jun  8 20:47 /usr/bin/less
3

Sounds like a SELinux error…

@OldButNotGuru If you follow the forum link in the side panel to the SELinux Portal and in the troubleshooting link run through the ausearch checks for the issue…

4

Thanks, @malcolmlewis. Some output from ausearch:

$ ~ sudo ausearch -ts boot -m avc,user_avc,selinux_err,user_selinux_err | grep less | tail -1
[sudo] password for root: 
type=AVC msg=audit(1786301563.996:3213): apparmor="DENIED" operation="exec" class="file" profile="/usr/bin/lessopen.sh" name="/usr/bin/lua5.4" pid=470893 comm="addto" requested_mask="x" denied_mask="x" fsuid=500 ouid=0

Also thanks for the link to the SELinux portal. Before I file a bugzilla report following the instructions there, I’m going to:

  1. zypper dist-upgrade my Slowroll to the latest release (I’m behind by two, including the major “9th of the month” update) to see if that fixes the problem.
  2. Install sestatus and audit2allow (again as per the Portal instructions) which my Slowroll doesn’t have.

But … related to #2 (maybe I have a bad SELinux install?) I also seem to have AppArmor installed and running on the system:

$ aa-status | grep -i -C1 less
156 profiles are in enforce mode.
   /usr/bin/lessopen.sh
   /usr/bin/{p,}locate
--
   qutebrowser
   rootlesskit
   rpm

$ systemctl status apparmor
● apparmor.service - Load AppArmor profiles
     Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; preset:>
     Active: active (exited) since Tue 2026-08-04 14:24:59 PDT; 4 days ago
 Invocation: 14217edb5b8e4e13817bdafda63c4719
       Docs: man:apparmor(7)
             https://gitlab.com/apparmor/apparmor/wikis/home/
    Process: 1243 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited,>
   Main PID: 1243 (code=exited, status=0/SUCCESS)
        CPU: 5.107s
Aug 04 14:24:59 dexter systemd[1]: Starting Load AppArmor profiles...
Aug 04 14:24:59 dexter apparmor.systemd[1243]: Restarting AppArmor
Aug 04 14:24:59 dexter apparmor.systemd[1243]: Reloading AppArmor profiles
Aug 04 14:24:59 dexter systemd[1]: Finished Load AppArmor profiles.

$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-7.1.5-1.0.10.sr20260707-default root=UUID=230427e5-dd8f-4a08-acbf-f035359a38b3 splash=silent mitigations=auto quiet security=apparmor

I researched this online, and although I know that Google A.I. can make horrible mistakes it emphatically states that a Linux system can’t have both SELinux and AppArmor running at the same time.

Is my Slowroll running both, and could that – not a bug or misconfiguration in SELinux – be causing the problem? Note the output from aa-status above that seems to show AppArmor is doing something with /usr/bin/lessopen.sh.

Google A.I. also said that Tumbleweed had moved from AppArmor to SELinux, and that it was possible that an old Tumbleweed with AppArmor that had been converted to Slowroll might still have it. My Slowroll was converted from a July 2023 Tumbleweed install.

  1. Is it in fact normal to have both SELinux and AppArmor installed/running?
  2. If not, should I try to zypper remove all AppArmor packages/patterns? I currently have:
$  zypper search -i armor
Loading repository data...
Reading installed packages...

S  | Name                           | Summary                          | Type
---+--------------------------------+----------------------------------+--------
i+ | apparmor                       | AppArmor                         | pattern
i  | apparmor-abstractions          | AppArmor abstractions and dire-> | package
i  | apparmor-docs                  | AppArmor Documentation package   | package
i  | apparmor-parser                | AppArmor userlevel parser util-> | package
i  | apparmor-profiles              | AppArmor profiles that are loa-> | package
i  | apparmor-utils                 | AppArmor User-Level Utilities -> | package
i  | libapparmor-devel              | Development headers and librar-> | package
i  | libapparmor1                   | Utility library for AppArmor     | package
i+ | lua-lmod-apparmor-abstractions | Apparmor bash Abstraction for -> | package
i  | passt-apparmor                 | Apparmor profiles for passt an-> | package
i+ | patterns-base-apparmor         | AppArmor                         | package
i  | plocate-apparmor               | Apparmor profiles for plocate    | package
i  | python3-apparmor               | Python 3 interface for libappa-> | package
i  | yast2-apparmor                 | YaST2 - Plugins for AppArmor P-> | package

Thanks for any suggestions on how best to proceed. Other than wanting to report a bug if in fact there is one, my original problem with less isn’t critical, but now I’m wondering if I have potentially more serious SELinux/AppArmor issues.

5

Your 2023 Slowroll installation predates the switch to SELinux, so not surprising that the original AppArmor configuration is still active. You can verify with…

cat /sys/kernel/security/lsm
getenforce

Anyway, the aa-status output confirms that it is enforcing the /usr/bin/lessopen.sh profile.

You can test by temporarily putting that profile into complain mode…

sudo aa-complain /usr/bin/lessopen.sh

then run your less command again. If it succeeds this time, AppArmor is the cause.

6

Multiple primary LSM modules still isn’t possible. Iirc its a third LSM (SMACK) author who has been working on this. However, it will eventually also depend on the modules themselves supporting it, I doubt the 2 major primary LSM modules apparmor, selinux will once/if it ever happens.

https://lwn.net/Articles/804906/ (for those interested)

7

Thanks, @deano_ferrari. I have:

$ cat /sys/kernel/security/lsm 
lockdown,capability,landlock,yama,apparmor,bpf,ima,evm$

$ which getenforce
getenforce not found
$ sudo getenforce
[sudo] password for root: 
sudo: getenforce: command not found

I tried writing a small C program to print the results of selinux_getenforcemode() and selinux_status_getenforce(), but both calls fail with -1 error codes.

Yes, AppArmor is definitely doing it:

$ less mygetenforce.c
Failed to execute target.: Permission denied
$ sudo aa-complain /usr/bin/lessopen.sh
Setting /usr/bin/lessopen.sh to complain mode.
$ less mygetenforce.c                    
$

So is the following my best way out of this mess, including what looks to be a partial/broken SELinux? Again, I got here because I initially installed Tumbleweed onto a fresh partition in 2023, then converted it to Slowroll in 2025 following what were listed as best practices in https://en.opensuse.org/Portal:Slowroll at the time. (I don’t remember, but I don’t think opensuse-migration-tool was around at the time.)

  1. zypper dist-upgrade to the latest Slowroll.
  2. zypper remove all the AppArmor packages and patterns listed in my previous post. Is that the complete list? Would just removing patterns-base-apparmor do the trick?
  3. Maybe zypper install selinux-tools (anything else?) to get what I seem to be missing?
  4. Change my “security=apparmor” to “security=selinux” (is that the correct syntax?) in /etc/proc/cmdline?

Thanks for corrections and tips to keep me from ending up with an unbootable Slowroll system. :frowning:

8

No Apparmor is the active LSM.

If you wish to migrate to SELinuxread the following guide:

https://en.opensuse.org/Portal:SELinux/Setup#Tumbleweed

9

Sorry, I’m confused now. I don’t “wish” to migrate to SELinux, and neither do I have any reason to want to stay with AppArmor. From this thread and other sources I thought that:

  1. It’s impossible – or at least bad – to have both AppArmor and SELinux on the same system, and …
  2. SELinux is the current/default/recommended LSM for Thunderbird/Slowroll. (“For new installations you can choose “SELinux” as security system instead of “AppArmor” in the installer …” at the Wiki.)

Regardless whether my less problem is now permanently fixed, and/or whether I’ll have any other future ones, I think I’d be best served by fixing my Slowroll to be as close to a standard install as possible.

By writing “Apparmor is the active LSM” did you just mean I shouldn’t zypper remove it before I have SELinux fully up and running? So I should just follow all the steps at https://en.opensuse.org/Portal:SELinux/Setup#Tumbleweed, confirm SELinux is working correctly, and then remove AppArmor? Or just leave it, disabled because it’s not in /etc/proc/cmdline any more?

Or should I give up, maybe uninstall SELinux (the “no two LSMs” rule) (except won’t it just come back with every zypper dist-upgrade?) , and stay with AppArmor? Sorry, I’m not trying to be difficult, I just don’t want to have to come back here begging “please help me restore my completely broken system”.

10

Please don’t disable these, this is not the way.

I say keep apparmor (cuz selinux is even worse for users close to giving up, you need 100% coverage with profiles), but learn to fix these profiles, apparmor is easy compared to selinux - its not that hard, everyone can figure it out. One of the contributors and maintainers @cboltz also hang out in OpenSUSE so I’m sure he will happily point in the direction or correct me if I’m wrong…

You have a minor issue, the issue is caused by non-standard less configuration. You probably changed your default pager with export PAGER= to something fancy like bat, nvimor another one of these :rocket: github pager projects.

The solution is straightforward afaik… You add the override;

echo '/usr/bin/lua5.4 mrix,' | sudo tee -a /etc/apparmor.d/local/usr.bin.lessopen.sh
sudo apparmor_parser -r /etc/apparmor.d/usr.bin.lessopen.sh

Something like that…

2 Likes
11

I was just confirming that Appamor is active and SELinux is not. So this statement is not the issue…

Fix the profile as dezza suggests. General idea is to put it into complain mode for the binary concerned with sudo aa-complain /path/to/binary, and then run the application through its normal tasks so it triggers logged events. Run the log profiler to update rules: sudo aa-logprof. Return the profile to enforce mode: sudo aa-enforce /path/to/binary.

1 Like
12

OK. Thanks, everyone. I’ll leave AppArmor installed and active (because it already is and it’s still supported even though SELinux is now the default), and also leave SELinux installed because it’s not active and not doing anything except maybe wasting disk space.

The sudo aa-complain /usr/bin/lessopen.sh fixes my problem but since I assume it won’t survive a reboot and I don’t want to have to redo it manually each time, I’ll try either the “lua5.4 mrix,”/etc. or the “aa-complain”/“aa-logprof”/aa-enforce" recipes to get it to stick permanently. (I don’t understand where lua is finding a"mrix.lua" source file when AppArmor runs it from a configuration file in apparmor.d, but I’ll try to figure it out.)

I apologize for wasting so much bandwidth here, but I think it should be understandable that I went from almost filing a bug with the upstream “less” maintainers, to chasing SELinux errors via ausearch, to finding that I had two LSMs installed and reading that that was fatal, and finally here. I understand that security messages are intentionally vague (you don’t want login failures to specifically say “bad password” vs “unknown user” because that gives an attacker information he might be able to use), but if AppArmor had output “AppArmor is blocking the execution of /usr/bin/lessopen.sh due to configured security policies” instead of “Failed to execute target.: Permission denied” (I spent several hours reading lessopen.sh and trying to figure out what process was trying to run the “.” directory as an executable binary) it would have saved me a lot of trouble and time posting here.

Thanks again for all the active openSUSE support.

13

The important thing is that you now understand the actual cause, and aa-logprof should make fixing the profile relatively straightforward.

No, it will survive a reboot, but better to use aa-logprof to add the required rule and then put the profile back into enforce mode (as already explained). That way you retain the protection of AppArmor rather than leaving the profile in complain mode.

1 Like
14

Write yourself a little cheatsheet with these commands and example of simple override. Fastest way to learn and gain some muscle memory.

You can learn a lot just by studying the builtin profiles, its the reference quality - some of them are intentionally very simple and easily understood - others have more advanced permissions.

Good luck!

15

Followup to mark post as solution and to question if the problem is truly a bug …

First:

@dezza:
You have a minor issue, the issue is caused by non-standard less configuration. You probably changed your default pager with export PAGER= to something fancy like bat, nvimor another one of these :rocket: github pager projects.

I don’t think that’s my situation. To the best of my knowledge I’ve never changed PAGER=

$ env | grep -i less
LESS=-M -I -R
LESS_ADVANCED_PREPROCESSOR=no
LESSKEY=/usr/etc/lesskey.bin
PAGER=less
LESSCLOSE=lessclose.sh %s %s
LESSOPEN=lessopen.sh %s
$

In any case, I did the posted solution (thanks again!) and of course it worked. No more error messages running less.

echo '/usr/bin/lua5.4 mrix,' | sudo tee -a /etc/apparmor.d/local/usr.bin.lessopen.sh
sudo apparmor_parser -r /etc/apparmor.d/usr.bin.lessopen.sh

I did enough reading about AppArmor that I understand why the fix worked, but what I don’t understand is why it’s needed.

$ file /usr/bin/less{,open.sh}
/usr/bin/less:        ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=c3f34f2668d8efafe55aa9b259061aae7edf0934, for GNU/Linux 4.3.0, stripped
/usr/bin/lessopen.sh: Bourne-Again shell script, ASCII text executable
$ grep -i lua /usr/bin/lessopen.sh 
$ strings /usr/bin/less | grep -i lua
$

Who is running lua{,5.4} that AppArmor is trapping without the fix? I guess the fact that I’m confused doesn’t matter, but I don’t like mysteries.

More important, and circling back to my env output above, shouldn’t the /etc/apparmor.d/usr.bin.lessopen.sh in the Slowroll repos have the necessary lua5.4 permissions without requiring a patch in/etc/apparmor.d/local? Yes, it’s a trivial problem (although I can’t understand why nobody else has seen it) but as with mysteries I don’t like bugs. Should I try to file this in Bugzilla?

16

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.