Hallo!
After upgrading from openSuse Leap 15.5 to openSuse Leap 15.6, I can now see an unexpected and new entry in the AppArmor log, when I execute sudo aa-logprof
I am pretty sure that zgrep does not need this access; I don’t see any additional relevant entries in journalctl, so this is not really a defect.
I am just wondering what process is using zgrep to access nameservices?
Hello and welcome to the openSUSE forums.
I have no idea about your problem, but a few hints about posting code next time.
When your system language is not English and you want to post in the English language part of the forums, please precede your command with LANG=C, in your case here:
LANG=C aa-logprof
And also please include the line with the prompt and the command that generates the output shown (and then there is no need for story telling like “when I execute …”), including all output and including the next prompt line (which then signals that this is the complete output).
Well, I am not sure that I am adding a lot of new information here, as I think my initial question contained all relevant information, but here is the output in your desired format:
xxx@ashes:~> su
ashes:/home/xxx # LANG=en_US.UTF-8
ashes:/home/xxx # LANGUAGE=en_US
ashes:/home/xxx # aa-logprof
Updating AppArmor profiles in /etc/apparmor.d.
Reading log entries from /var/log/audit/audit.log.
Complain-mode changes:
Enforce-mode changes:
Profile: zgrep
Path: /var/lib/nscd/passwd
New Mode: owner r
Severity: unknown
[1 - include <abstractions/nameservice>]
2 - owner /var/lib/nscd/passwd r,
(A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish
ashes:/home/xxx #
Please note that adding LANG=C does not change the output language in my terminal window. You need to set
Also note that I did not ask you to re-post what you already posted. As you are new here, I only informed you about the best way to post code in the future.
A welcome and a way to let you feel at home ASAP by telling you how we work efficient. That is all that I tried to do.
A software developer would understand that system calls, or calls to other standard commands, can be executed within some program. So, to discover “what might be calling what”, we would use strace.
So, now you can use your favorite text editor to open up “strace.log” to browse around and check all the calls.
And if you notice the above output, aa-logprofo output some text to the console. So, if you want that output to go to the “strace file”, so you can see each of the lines, and how they are being produced, you can do the following (and notice that we do not use the “-o filename” argument, but use redirection):
Thank you for your answer, but it is beside the point.
The problem is not what kind of syscalls aa-logprof is doing. aa-logprof is a tool to check AppArmor profile violations and is working fine, as far as I am concerned. When I call aa-logprof, it simply shows me the latest violations of existing AppArmor profiles, and zgrep is obviously constantly causing violations.
The real question is: why does zgrep constantly violate its default AppArmor profile? I cannot easily know it, because I don’t even know what kind of process, tool, daemon etc. is using zgrep all the time. I tried to grep all *.sh files to see where zgrep is used:
ashes:/ # find . -path "./mnt" -prune -o -name "*.sh" -type f -exec grep "zgrep" '{}' +
./usr/lib/dracut/modules.d/10i18n/module-setup.sh: *.gz) CMD="zgrep" ;;
./usr/lib/dracut/modules.d/10i18n/module-setup.sh: *.bz2) CMD="bzgrep" ;;
./usr/src/linux-5.14.21-150500.55.88/tools/testing/selftests/firmware/fw_lib.sh: if zgrep -q $1 $PROC_CONFIG 2>/dev/null; then
./usr/src/linux-6.4.0-150600.23.30/tools/testing/selftests/firmware/fw_lib.sh: if zgrep -q $1 $PROC_CONFIG 2>/dev/null; then
Then obviously I misunderstood the issue you are having. My understanding was, “zgrep should not be called by the aa-logprof command”.
I did analyze my “strace2.out” file. There are 15 references to “zgrep”, so my interpretation is, there is a dependency.
However, on your system, the question is
So yes, I understand … I do not see this violation.
So, as there are no other replies, might look for an AppArmor forum, or just do a global web search for the issue - folks using other distros may show the same issue.
Looks like avahi-daemon is using zgrep to access /var/lib/nscd/passwd which is then blocked by AppArmor.
I know too little about avahi-daemon to judge whether this makes sense or not…