I'm puzzled as to why this is happening. Maybe the use of a global hook defined using a separate file in mocha.opts is the answer? https://futurestud.io/tutorials/mocha-global-setup-and-teardown-before-after

Hmm, ignore the above. I realized my mistake. The set of rules I'm now running (instead of deny /** w is

Okay, I've managed to get your example running by replacing

In Rust, something similar happens with ld.so.cache. With the profile enforced:

Hmm, complain mode didn't change anything.

In T377468#10245656, @akosiaris wrote:

To debug apparmor profiles, an easy way is to add the complain flag. So, flags=(attach_disconnected) becomes flags=(complain) and the actions will be allowed and logged. That should some pretty specific hints as to what exactly would break in the "normal" (not fallbacks implemented in code to workaround failures) mode.

I tried using strace. Here's my new Dockerfile:

Interesting, yeah, I get a similar error with your source file and Dockerfile:

Hmm, weird! I am not on Mac (or are you saying you're on Mac?). I'll try running with your source file and Dockerfile.

Hmm. I get the same issue even when I add /dev/null rw to the profile.

For Rust, I found this: openat(AT_FDCWD, "/dev/null", O_RDWR) = -1 EACCES (Permission denied) , so looks like it's read + write. Interestingly, this openat call only happens when AppArmor is enabled.

I see. There are a few things going on here.

Hmm. I think the problem here is the use of Z17464, which is defined for references. The fully-resolved types that are returned are Z4/Types, not Z9/References. It seems to be that there should be a Type equality function for this case. Am I missing something?

New Numbers:

We do have other means of measuring this more granular time spans, but we don't expose them in the UI. It would be useful to exclude wait times when determining the fastest implementation.

We won't see them yet, no. Conceptually, there are three different interesting time spans in the evaluator:

Thanks to @DMartin-WMF for the numbers:

The above MR demonstrates that the evaluator can handle these escape sequences, and that they are interpreted correctly when injected into code with eval/exec (if they were not interpreted correctly, the regex matches would not have been correct).

@Harej : Just to be clear that it's the same issue, what happens if you double-escape all the Unicode sequences (e.g., \\u200e)?

I also see that this works if you double-escape, so the regex can be r'\\d'. This is still not great, but it should work for now.