Comment 7 for bug 1310598

Thanks Christian for the heavy lifting on the mailinglist and bzr.

I didn't understand, on the FAQ, about yielding permissions to Canonical. Is that about proposing patches on Launchpad itself, or does it also apply for projects hosted on launchpad.
Anyway, to whomever, Canonical or "upstream team" for aa-status, I grant all rights for that patch... and as a courtesy, as far as possible, I'll appreciate to be listed under the contributors *Alain BENEDETTI* (if there is such list of contributors for this project).

I'm also very sorry, I see that the launchpad munched the Python indentation in my diff quote. If you need a cleaner diff, I'll be glad to attach it, but I'm assuming you corrected the wrong indentations from the post above!

For the record I did also try to correct applying a locale. That is impractical because when aa-status is run first, from the apparmor script in the init.d, the environment has no locale. When you run it later, once connected to a session, that works because it then gets the locale of the session, which is generally UTF-8.
After further reading, I saw that the kernel considered mountpoints as binary strings, thus I did accordingly.

I also tested "security tricks", like naming a directory: "pwned securityfs" with a "space" (ASCII 0x20) in the name, which is totally legal, and same for "\n" which is also legal in paths!
Fortunately, that does break aa-status, because in such cases the kernel "escapes" the names, and you would get:
"pwned\040securityfs"... so all seems safe for security, even if you try fancy mountpoints!

(otherwise I would have opened another undisclosed ticket)

Regards.
Alain