I thought I had replied to this one but doesn't look like I did in the end.
I think this one potentially has a close relationship with the need for permissions that we were discussing on the other thread - i.e. deployments manipulating the settings of other deployments. Once we start to have APIs for deployments self managing their security those prior needs reduce.
I think that the consensus seems to be, more or less, and at least according to the Java SE team, that deployments in a Jakarta EE server are not really independent applications that need to be protected against each other. They are more like cooperating modules of a single logical application.
So I didn't think permissions were really needed here at all in the first place, but soon those types of permissions won't be easily enforceable anyway.
That being said, deployments manipulating the settings of other deployments is a somewhat rare use case. The API puts this really front and centre, while in practice you mostly want to do things for the current application. Also notice that if deployment A contains a ServerAuthModule that it sets for deployment B, class loading issues may occur. Probably a .rar deployment can do this more correctly since I think it gets a lower level server classloader, but using .rars is also not that common these days.
The server vendor can put this API of course to good use though, when the server itself reads e.g. a config file with e.g. server auth modules targeted at specific applications.
Kind regards,
Arjan
