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?

3

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.

  • 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. – jah May 10 '16 at 13:14
  • 2
    It turns out that mame wasn't the culprit: firejail --trace creates an empty /etc/ld.so.preload. – jah May 11 '16 at 9:02

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.