Latest Spigot 1.12 build (build at time of reporting) running without plugins to rule out 3rd party influences. Running on FreeBSD with latest OpenJDK8.

First: still appreciating you taking your time here but I'm confused: who is insulting who? Sure, I was a bit cynical up there with my "Mojang adding functions to advancements" because I can't help feel that not too many people realize the impact which advancements have. But I still stand behind everything I said.

However...  I definitely see your point here and I'd like to thank you once again for taking your time. But I do think this is heading into dangerous slopes. One can only imagine what would happen if custom recipes trigger functions. If you pick those comments up as being insulting then...  I think the problem is not with me here.

Read my message before insulting me.
I fixed your behaviour.

Commands in Minecraft have permission levels.
Advancements can execute commands with permission level up to and including level 2.

Bukkit does not have permission levels, it has string based permissions.

Your confusion comes from trying to reconcile permission levels with string permissions.
I do not see a way to resolve this without getting rid of the flexibility that string based permissions have.

Maybe a permissions context system could be implemented to allow assigning permissions to players depending on their execution environment, but that requires large scale changes to both Bukkit and permissions plugins, far outside the scope of a bug fix.

Functions are a minimal substitute for the flexibility provided by Java plugins and also things such as Skript, which have been used for years and are no harder to write than functions, but have 100x the capabilities.

We've done our best to implement functions and advancements into Bukkit, but there are irreconcilable differences as a result of Bukkit being about five years ahead.

That being said I have added an unrestricted-commands option to commands.yml to COMPLETELY BYPASS any permissions check on the commands themselves.

First of all: thank you for your comment, I appreciate your time. But your assumption is wrong. Thing is: I have a clean testing server without any plugins overriding permissions, and custom advancements are not working as they should, that's why I initially marked this bug as major.

See, in my last bug report I made (few months back) I did make the stupid mistake you describe here. And I'm still sorry for wasting peoples time over that; I'm not making that mistake ever again. Ever since that happened I started maintaining a separate (vanilla) server, only accessible through LAN/VPN for the sole purpose of testing. No plugins, nothing other than what needs to be tested.

In this testing setup I only added my custom advancements and functions and nothing else. And I tell you: the moment a regular user triggers an advancement which uses a function then the user gets an error when the function contains commands which only OPs can perform like /give. And it shouldn't,

Because it works in vanilla, but also because it's highly inconsistent with that same user triggering a command block which contains: "execute @p ~ ~ ~ function catslair:same/function", because then the function does get executed as normal, even with /give, /tp and whatever other OP only command.

And just to go the extra mileage I also tested this with Spigot 1.12.1 and it behaves in the same inconsistent way.

See: https://puu.sh/x2pNe/518e1ad083.png

(bedrock: revoke all advancements, sandstone: trigger the attached advancement, cobblestone: directly trigger the attached function).

(edit): I also fail to see how command-block-overrides would influence a custom advancement which gets triggered from a player entering a specific area or killing a specific mob.

(edit2): In the mean time I tried as you said with the * for command-block-overrides but as I expected up front that doesn't change a thing.

I guess the only way to make you see the problem here is when Mojang starts using function rewards in their vanilla advancements. Because in its current state that would seriously break in Spigot. Can't say I didn't warn you.

No the executor should not be the server.

Bukkit can allow you to set permissions for individual commands, including for example /function.
If you have a clean server with no plugins overriding commands or permissions then when you are op this will behave exactly as expected.
The issue is you have a PLUGIN overriding /give which is checking for a permission other than op which the player does not have.

If you want to use the vanilla commands instead of plugins which will work fine for OPPED players, then add '*' as a command block override in commands.yml.

There is no bug here, this is a configuration and/or plugin issue

But the executor should be the server; it's the system which detected the advancement being triggered and thus gave out optional rewards (XP & loot table triggers).

This really makes 0 sense, because from your perspective a: "execute @p ~ ~ ~ function <function>" also shouldn't work because the player basically executed it. Yet that doesn't happen.

Security really is non-issue here because players can't trigger functions in the first place, /function is an OP only command.

Sorry to insist but this seriously breaks the advancement functionality and basically renders them pretty much useless, which I think isn't a smart thing to do.

Functions execute with the permissions of their executor.
This is for obvious security reasons.
In Bukkit everything has unique permissions including command blocks.