You may be better to ask internals@php.net so that someone who know fpm to commit this. I would like to help you, but I don't use apparmor.

@yohgaki this was already diskussen on internals and there is an rfc for it; but there were only three votes. So it was suggested to contact the maintainers of fpm - but they haven't answered so far :(

I know the discussion and I know there are many cases that good patches are forgotten. Since this is new feature that only applied to master, I may merge the patch if there is good test scripts for this change.

I cannot help making test script as I don't use apparmor, though. Could you provide test script?

I'd be happy to write a test script. But at the moment I'm not really sure how:

• To test if the change to the profile works it is needed that the profile is in place. If I write a script that creates and activates such a profile it would need root rights and play around with apparmor. I don't know if it is a good idea to do that - it could seriously damage the system of the tester :(.
• Your system would need apparmor to test it
• Hmm well there is another issue with fpm, that if a child dies during start up, the master does not really notice (except that the child died) and it will restart it and the log entries provided by the child end up in nirvana. Meaning that if the profile switching fails the master does endless forks and a lot of log is generated... But this isn't in the scope of this patch and I wanted to create a separate one which addresses this, because it affects the other start up stuff too (eg. chroot, chdir, set gid, ..)

So right now it is a bit hard to create a test.
If you're ok with this concerns I would write a test script that:

• creates a profile
• creates a testpoolconfig
• fires up php-fpm and checks if the pools have the right profiles

Maybe I can detect from the log file, that the profile change went wrong and can test the error cases. But at the moment two things can happen:

• I found a segfault in apparmor, which is already fixed in the latest version - but it might take some time till that reaches the masses
• Something else could go wrong. Because of the missing log entries one can't be sure

Because of all of this I wouldn't recommend putting that into the php sources. I could try to provide virtual machine image which has everything set up for testing.

On a completely unrelated note: I could rewrite the whole thing to not require libapparmor and talk directly to the kernel. Would be one less dependency and IMHO shouldn't have any disadvantages.

It is possible to get a partial test, to where you can make a change_hat/profile call and get an error code returned by apparmor without having to load policy.

change_profile will return ENOENT when it can't find the specified profile
change_hat: ENOENT if confined, the profile has hats but not the specified hat
ECHILD if confined, but the profile doesn't have hats
EPERM if called from unconfined

Upstream apparmor would also be willing to carry a regression test, which could do the policy loads etc, for this if that would help.

Sry for taking so long; I had some other stuff going on and I didn't want to just write some small test script, but create phpt tests for fpm and some helpful scripts for adding more tests in the future.

Sadly I had to write a new command line option for fpm (--force-stderr) so I can catch the error log in the tests. Without this php-fpm detects that stderr is not a TTY and just rejects to write to it. I hope this small change is not a big problem for this patch.

I wanted to test more, but since root privileges are needed for detecting anything apparmor related (existing profiles, if it is running, ...) I just added a test that tries to switch to a non existent hat if apparmor is compiled in.

Hello!
Was just investigating this feature some more - is this still within the php-fpm project? (for php 7 as well?) Is it documented?

As far as I can see, it is still part of php (checked the current master).
It only works if php-fpm was compiled with libapparmor.

Usage:
In the pool config you can change the apparmor hat of a pool by setting apparmor_hat to the desired hat. With this config set, this pool will change to this hat during spawning a worker.
Examples for hat configs: http://wiki.apparmor.net/index.php/Mod_apparmor_example (= the same functionality for apache)

Thanks! My understanding is that there's usually a parent policy in place
here then, and the hat would be a child's policy, correct?

Appreciate you taking the time!
On Wed, Sep 14, 2016 at 03:00 Gernot Vormayr notifications@github.com
wrote:

As far as I can see, it is still part of php (checked the current master).
It only works if php-fpm was compiled with libapparmor.

Usage:
In the pool config you can change the apparmor hat of a pool by setting
apparmor_hat to the desired hat. With this config set, this pool will
change to this hat during spawning a worker.
Examples for hat configs:
http://wiki.apparmor.net/index.php/Mod_apparmor_example (= the same
functionality for apache)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#373 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAch0_59Lp66W7ZYIj7KxJXEO78-gYeHks5qp6mrgaJpZM4AyFoO
.

On 09/14/2016 04:03 AM, Chris Fidao wrote:

Thanks! My understanding is that there's usually a parent policy in place
here then, and the hat would be a child's policy, correct?

correct, a hat is a special child profile that can be entered using the
aa_change_hat api.

Appreciate you taking the time!
On Wed, Sep 14, 2016 at 03:00 Gernot Vormayr notifications@github.com
wrote:

As far as I can see, it is still part of php (checked the current master).
It only works if php-fpm was compiled with libapparmor.

Usage:
In the pool config you can change the apparmor hat of a pool by setting
apparmor_hat to the desired hat. With this config set, this pool will
change to this hat during spawning a worker.
Examples for hat configs:
http://wiki.apparmor.net/index.php/Mod_apparmor_example (= the same
functionality for apache)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#373 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAch0_59Lp66W7ZYIj7KxJXEO78-gYeHks5qp6mrgaJpZM4AyFoO
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #373 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AEm7MSx0YNYZveYq_qXCDDa8RcIa2znVks5qp9R8gaJpZM4AyFoO.