3

Apparmor enforcement messages have begun appearing in the syslog of a Trisquel 7 machine. The affected programs requested open of the file /etc/ld.so.preload, in read mode and were denied by apparmor policy. The following is the very first instance of the message:-

May 8 21:25:54 box kernel: [928193.797140] type=1400 audit(1462739154.627:76): \ apparmor="DENIED" operation="open" profile="/usr/lib/NetworkManager/nm-dhcp-client.action" \ name="/etc/ld.so.preload" pid=13471 comm="nm-dhcp-client." requested_mask="r" \ denied_mask="r" fsuid=0 ouid=0

Some other apparmor constrained programs are being denied the same request, including cupsd and mysqld.

The apparmor profiles have not changed and these messages have never appeared before - so it seems that these (and perhaps other, non-constrained) programs have suddenly started trying to read the (empty) file /etc/ld.so.preload.

My only clue is that earlier that day I had compiled mame for the first time. I ran an emulated machine some time before that first message and left it running unattended. The host machine became unresponsive shortly after I returned to it and I had to reset it about 20 minutes after that message.

So could these two things be related and where should I start looking to find out why those programs are now looking for preloading libraries?

Improve this question

1 Answer 1

Reset to default
7

All programs try to open /etc/ld.so.preload, this behavior is baked into Glibc. But they only try to open it if it exists (Glibc first calls access).

Normally /etc/ld.so.preload doesn't exist, so each process just calls access, gets a negative answer and moves on. This doesn't trigger anything from AppArmor.

But if the file exists, then the processes call open to read from it. If the file is empty, dynamic linking is not affected, and the only effect is a very slight performance hit. If there's an AppArmor rule that triggers when some programs open the file, then you get those warnings.

I don't know if compiling mame might end up creating /etc/ld.so.preload, or if it's unrelated. In any case, if the file is empty, just remove it.

Improve this answer
2
  • Thank you @Gilles, nice answer. The ld.so.preload did not exist until about an hour before the first apparmor denial and the time stamp suggests that the file was created not while mame was being compiled, but perhaps during the time I was trying and failing to emulate a machine. Removing ld.so.preload did indeed stop programs wanting to open it. Commented May 10, 2016 at 13:14
  • 2
    It turns out that mame wasn't the culprit: firejail --trace creates an empty /etc/ld.so.preload. Commented May 11, 2016 at 9:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.