MUGEN doesn't start if Apparmor is running

On Sat, Feb 09, 2008 at 06:12:00PM -0000, Daedalus wrote:
> As you can read, the strange thing is that MUGEN doesn't run even with
> "Ux" permission into the entire filesystem!

Which version of the kernel are you using ?

Could you post the log entries that are failing ?

  status incomplete

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Well, I don't remember well which kernel version I used, because for another reason I had to format and reinstall Gutsy. It was, however, the Hardy alpha 4 kernel for 386 (2.6.24-something-386...).
In the link mentioned above there are all log entries. I'll write here briefly:

I have created a profile for MUGEN (it is, in my case, in /home/deda/mugen)
and I have monitored /var/log/messages and /var/log/syslog (it seems that entries related to apparmor are same).

I started MUGEN, ok it doesn't work.

Here is /var/log/syslog output:

Feb 6 15:22:45 kubuntu kernel: [ 1725.519674] audit(1202307765.222:6): operation="inode_create" request_mask="w::" denied_mask="w::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
Feb 6 15:22:45 kubuntu kernel: [ 1725.519707] audit(1202307765.222:7): operation="setattr" request_mask="w::" denied_mask="w::" attribute="size,mtime,ctime," name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
Feb 6 15:22:45 kubuntu kernel: [ 1726.005895] audit(1202307765.710:8): operation="inode_permission" request_mask="r::" denied_mask="r::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
Feb 6 15:22:45 kubuntu kernel: [ 1726.005928] audit(1202307765.710:9): operation="inode_permission" request_mask="rUx::" denied_mask="rUx::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
Feb 6 15:22:45 kubuntu kernel: [ 1726.005940] audit(1202307765.710:10): operation="inode_unlink" request_mask="w::" denied_mask="w::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
Feb 6 15:22:45 kubuntu kernel: [ 1726.005962] audit(1202307765.710:11): operation="inode_permission" request_mask="Ux::" denied_mask="Ux::" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"

This is /var/log/messages output:

[ 1725.519674] audit(1202307765.222:6): operation="inode_create" request_mask="w::" denied_mask="w::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
[ 1725.519707] audit(1202307765.222:7): operation="setattr" request_mask="w::" denied_mask="w::" attribute="size,mtime,ctime," name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
[ 1726.005895] audit(1202307765.710:8): operation="inode_permission" request_mask="r::" denied_mask="r::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
[ 1726.005928] audit(1202307765.710:9): operation="inode_permission" request_mask="rUx::" denied_mask="rUx::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
[ 1726.005940] audit(1202307765.710:10): operation="inode_unlink" request_mask="w::" denied_mask="w::" name="/tmp/upxBOSMZWCAHVV" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
[ 1726.005962] audit(1202307765.710:11): operation="inode_permission" request_mask="Ux::" denied_mask="Ux::" pid=7861 profile="/home/deda/mugen/mugen" namespace="default"
[ 1726.005974] AppArmor: aa_register: Failed to get filename

So I modified /etc/apparmor.d/home.deda.mu...

Deadalus,

Thankyou for the bug report, not getting a name in that reject message is definitely a bug, and it is being investigated.

AppArmor can be completely disabled at boot by adding

apparmor=0

to your kernels boot parameters.

Very well then, thanks for the workaround :)
Soon I will switch to Hardy again, so I will can do more experiments with Apparmor (it's never a good idea to disable a security feature for playing, isn't it?)

Ok, I have upgraded to Hardy Alpha6 (kernel 2.6.24-12-386), this bug still persists.
Come on guys, there is someone that could download MUGEN and try to run it using apparmor profiles? And that could set this bug as "confirmed" or "invalid" or something different than "incomplete"?? :-)

well, I can confirm it, and even provide some insight.

MUGEN does some very uhm interesting things on startup. It creates a new elf file in tmp, uses open to pin the file and then it deletes it. This results in the file being removed from the namespace and completely inaccessable except to processes that already have the file open. It then passes /proc/<pid>/fd/<mugen tmp file> to execve as the file to open, AppArmor is detecting that this is a deleted inaccessible file and failing the exec.

This is unfortunate in that this happens even when mugen is run from an unconfined shell, because AppArmor can't determine whether it should attach confinement to it. I will see what I can do, but any fixes if taken will have to come in a kernel update.

hrmm, well it seems I did fix this for unconfined processes before the final version of hardy (I remember fixing it for AppArmor 2.3 but I thought the fix missed Hardy), and my test machine wasn't properly updating. So after a fresh install MUGEN now works.

So to clarify, in Hardy MUGEN will run as long as it is started from an unconfined shell, and it does not have a profile defined for it. It is extremely unlikely that AppArmor in Hardy will be patched to support this behavior from a confined process.

Thank you for the explaination. Now many things are clear :)
Just a thing that I don't have understood... can you please explain me what is an "unconfined shell" and how to run it?

Thanks.

Looks like in Intrepid this bug is no more. Can we say "fix released"?

Per user's comment, this was fixed in 8.10.