To properly perform access control on activities inside build steps, we need executors to carry an Authentication object just like HTTP request handling threads do. In effect, a build is going to impersonate someone (or a subset of someone) while it executes, and when a build tries to access other things inside Jenkins (be it artifacts from another build, access to a slave, etc.), it'll be automatically subject to the same error checks that request handling threads g et.

The major unresolved question has been how/who determines which build carries which Authentication object, as there are several use cases:

• imod told me in the past that his environment enforces a naming convention for all the jobs, and that's enough to programmatically determine the identity that the build will run under. His environment also ties AuthorizationStrategy based on the job names, so this creates an effective access control.
• In a Jenkins instance with the folder plugin, a folder that the jobs are in could determine the identity of the build (in much the same way the naming convention works.)
• Sometimes it might be appropriate to run the build with the identity of the user who triggered a build. (or is it? what's the concrete use case?)
• Sometimes perhaps it should allow the user to click a button in the job config screen to let the build run as that user. This is obviously a sensitive operation as the job configuration can be updated by someone else after that.

All this seems to point toward the direction of making this pluggable, which makes sense. OTOH, if this is pluggable, what should be the default implementation?