Bugzilla – Bug 1206957
lua-lmod Permission denied in init/bash
Last modified: 2023-01-14 18:46:32 UTC
When calling `less` over a file I can see this output at the exit: > less /usr/share/lmod/8.7.15/init/bash /usr/share/lmod/8.7.15/init/bash: line 57: /usr/bin/readlink: Permission denied /usr/share/lmod/8.7.15/init/bash: line 61: /usr/bin/expr: Permission denied /usr/share/lmod/8.7.15/init/bash: line 62: /usr/bin/basename: Permission denied I did not dig into the bug, but this file seems not to be updated in the last version in git.
Seems to be an apparmor related issue: from /var/log/audit/audit.log: type=AVC msg=audit(1673254728.860:235): apparmor="DENIED" operation="exec" profile="/usr/bin/lessopen.sh" name ="/usr/bin/readlink" pid=6441 comm="lessopen.sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 type=AVC msg=audit(1673254728.860:236): apparmor="DENIED" operation="exec" profile="/usr/bin/lessopen.sh" name ="/usr/bin/expr" pid=6442 comm="lessopen.sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 type=AVC msg=audit(1673254728.860:237): apparmor="DENIED" operation="exec" profile="/usr/bin/lessopen.sh" name ="/usr/bin/basename" pid=6443 comm="lessopen.sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Maybe related with https://bugzilla.opensuse.org/show_bug.cgi?id=1065388
@Alberto, Indeed, it is gone after disabling apparmor and rebooting. But I don't think this is an lmod issue. Lmod seems to be working - at least the 'module' command is present: $ eich@localhost:~> module avail ------------------------- /usr/share/lmod/modulefiles -------------------------- gnu/12 $ module load gnu $ module avail ---------------------- /usr/share/lmod/moduledeps/gnu-12 ----------------------- hdf5/1.12.2 netcdf-cxx4/4.3.1 openmpi/4.1.4 mpich/4.0.2 netcdf/4.9.0 ------------------------- /usr/share/lmod/modulefiles -------------------------- gnu/12 (L) Where: L: Module is loaded Alberto: Where do you see a regression in the functionality of Lmod?
(In reply to Egbert Eich from comment #3) > @Alberto, Indeed, it is gone after disabling apparmor and rebooting. > > But I don't think this is an lmod issue. Lmod seems to be working - at least > the 'module' command is present: > > $ eich@localhost:~> module avail > Alberto: Where do you see a regression in the functionality of Lmod? Ok. You are right. I will mark it as a duplicate of the referenced one in another comment. *** This bug has been marked as a duplicate of bug 1065388 ***
No it's not a duplicate. lmod is doing nasty things here and pollutes the shell environment via /etc/profile.d/lmod.sh. My strong advice would be not do that. Instead there could be eg. only something like an "lmod-activate" or "lmod-enter" alias that sources /usr/share/lmod/8.7.15/init/bash *on demand* rather than for each and every shell of each and every user.
(In reply to Ludwig Nussel from comment #5) > No it's not a duplicate. Ah OK. My bad then, yes. > lmod is doing nasty things here and pollutes the > shell environment via /etc/profile.d/lmod.sh. This seems to be true. But there is a regressions somewhere in lmod, lesscode or apparmor, as this was not there until the last update. > My strong advice would be not > do that. Instead there could be eg. only something like an "lmod-activate" > or "lmod-enter" alias that sources /usr/share/lmod/8.7.15/init/bash *on > demand* rather than for each and every shell of each and every user. No idea here, but seems to be a core feature of lmod to enable / disable module without user interaction, nor logout / login routine. I guess that you get dragged here because one change in the apparmor spec that seems unrelated (usermerge). The other package the changed was lmod. Less did no change recently.
Looks like lessopen.sh wants to execute some more binaries. Since readlink, expr and basename are "harmless", the most boring solution is to allow executing them ;-) Please add the following lines to /etc/apparmor.d/local/usr.bin.lessopen.sh: /usr/bin/readlink ix, /usr/bin/expr ix, /usr/bin/basename ix, Then run rcapparmor reload and try again. Please report back if everything works with this addition or if you get more/other DENIED log lines.
(In reply to Christian Boltz from comment #7) > Looks like lessopen.sh wants to execute some more binaries. I think that this is the issue. It is not lessopen.sh the one that want to execute those binaries, but /usr/share/lmod/8.7.15/init/bash. IIUC it is less that is sourcing BASH_ENV explicitly, but there can be others doing the same (maybe sshd)
(In reply to Alberto Planas Dominguez from comment #8) > IIUC it is less that is sourcing BASH_ENV explicitly No. I must be corrected. It is Bash the one that source it in non-interactive shells: $ echo $BASH_ENV /usr/share/lmod/8.7.15/init/bash $ cat test.sh echo "Hi" $ export BASH_ENV=$HOME/test.sh $ bash -c "ls /" Hi bin boot dev etc ... We see the issue in lessopen.sh because it is confined in enforced more, but aa-status shows more there. Any other launching a non-interactive bash will have the same error, as will execute the same "/usr/share/lmod/8.7.15/init/bash"
(In reply to Ludwig Nussel from comment #5) > No it's not a duplicate. lmod is doing nasty things here and pollutes the > shell environment via /etc/profile.d/lmod.sh. My strong advice would be not > do that. Instead there could be eg. only something like an "lmod-activate" > or "lmod-enter" alias that sources /usr/share/lmod/8.7.15/init/bash *on > demand* rather than for each and every shell of each and every user. This would break every existing job scripts for users. We cannot do this. 'module load' needs to work in a batch environment from inside shell scripts. This is why BASH_ENV is set. Also, it is expected that every (physical) user logging into a system with Lmod installed will actually need it. On non-HPC systems, the lua-lmod package should not be installed. We can mitigate the impact of having BASH_ENV set by delaying the offending operations - which have been added recently - until when the 'module' command is actually run. This should fix the issue for lessopen.sh and possibly any other non-interactive calls to bash.
https://github.com/TACC/Lmod/issues/620 https://github.com/TACC/Lmod/pull/621
Fixed in Factory: SR:1057160
This is an autogenerated message for OBS integration: This bug (1206957) was mentioned in https://build.opensuse.org/request/show/1057160 Factory / lua-lmod
(In reply to Egbert Eich from comment #10) > (In reply to Ludwig Nussel from comment #5) > > No it's not a duplicate. lmod is doing nasty things here and pollutes the > > shell environment via /etc/profile.d/lmod.sh. My strong advice would be not > > do that. Instead there could be eg. only something like an "lmod-activate" > > or "lmod-enter" alias that sources /usr/share/lmod/8.7.15/init/bash *on > > demand* rather than for each and every shell of each and every user. > > This would break every existing job scripts for users. We cannot do this. > 'module load' needs to work in a batch environment from inside shell > scripts. This is why BASH_ENV is set. > Also, it is expected that every (physical) user logging into a system with > Lmod installed will actually need it. On non-HPC systems, the lua-lmod > package should not be installed. There is nothing that prevents lua-lmod from being installed in a normal system. In fact the description sounds very generic and has no reference to specific HPC setups. Introducing a generic command called "module" and even a two letter one, ie "ml" looks rather dangerous to me. How can we as distribution make sure that no other package introduces those commands too? How to make sure noone else uses BASH_ENV for some other magic?
(In reply to Ludwig Nussel from comment #15) > (In reply to Egbert Eich from comment #10) > > (In reply to Ludwig Nussel from comment #5) > > > No it's not a duplicate. lmod is doing nasty things here and pollutes the > > > shell environment via /etc/profile.d/lmod.sh. My strong advice would be not > > > do that. Instead there could be eg. only something like an "lmod-activate" > > > or "lmod-enter" alias that sources /usr/share/lmod/8.7.15/init/bash *on > > > demand* rather than for each and every shell of each and every user. > > > > This would break every existing job scripts for users. We cannot do this. > > 'module load' needs to work in a batch environment from inside shell > > scripts. This is why BASH_ENV is set. > > Also, it is expected that every (physical) user logging into a system with > > Lmod installed will actually need it. On non-HPC systems, the lua-lmod > > package should not be installed. > > There is nothing that prevents lua-lmod from being installed in a normal > system. In fact the description sounds very generic and has no reference to > specific HPC setups. Introducing a generic command called "module" and even > a two letter one, ie "ml" looks rather dangerous to me. > How can we as distribution make sure that no other package introduces those > commands too? How to make sure noone else uses BASH_ENV for some other magic? The summary/description can be changed. There is no system in place on openSUSE installations preventing the installation of certain packages unless the underlying system serves a certain purpose. All in all I consider the risk of this happening rather low. We've been providing Lmod for 6 years, now, and we have not seen a single report of a user complaining. As of conflicting definitions of environment variables and aliases - I wonder if there is a 'Provides:' system available for such entities. I'll try to find out.