local connector owner option may be incorrect under flux-proxy(1)
#5530
Comments
|
The local connector is using the SO_PEERCRED peer identity (via Then the |
|
But then any time Is too onerous to fetch the Actually, I guess the other thing to try is to see the impact of just always signing jobspec. |
|
Hmm, maybe we could have the broker and flux-proxy both store the owner userid in an environment variable like FLUX_OWNER. Then the connector could use SO_PEERCRED to get the peer pid. If the peer uid matches getuid() then pull FLUX_OWNER out of the peer pid's environment and check that? Edit: oh duh, or just check FLUX_OWNER in the inherited environment :-) |
Problem: the SO_PEERCRED method of determing the flux owner to decide whether job requests must be signed using a strong (but slower) signing mech doesn't work with flux-proxy(1). Check an environment variable FLUX_OWNER instead. This can be set - in broker subprocesses (job, initial program, flux-exec(1)) - in a proxy shell by flux-proxy(1) after checking the security.owner broker attribute As noted in the code comment, signing with mech=none enables single user Flux instances that were compiled --with-security (as would likely be the case for all packaged flux deployments) to function without configuring munge. In addition, each munge_encode(3) and munge_decode(3) call includes a synchronous request-response round-trip to munged(8), which has a minor impact on job throughput and thus should be avoided when unnecessary. Fixes flux-framework#5530
Problem: flux-proxy(1) checks security.owner and, without --force, fails with an error if the owner does not match getuid(). Drop this code as the reason for it no longer exists. flux_job_submit() now checks security.owner instead of relying on the unix domain peer credential, so it works as expected over flux-proxy. Update sharness test. Fixes flux-framework#5530
Problem: flux-proxy(1) refuses to connect as a guest without --force. Drop this code as the reason for it no longer exists. flux_job_submit() now checks security.owner instead of relying on the unix domain peer credential, so it works as expected over flux-proxy. Update sharness test. Fixes flux-framework#5530
Problem: flux-proxy(1) refuses to connect as a guest without --force. Drop this code as the reason for it no longer exists. flux_job_submit() now checks security.owner instead of relying on the unix domain peer credential, so it works as expected over flux-proxy. Update sharness test. Fixes flux-framework#5530
Problem: flux-proxy(1) refuses to connect as a guest without --force. Drop this code as the reason for it no longer exists. flux_job_submit() now checks security.owner instead of relying on the unix domain peer credential, so it works as expected over flux-proxy. Update sharness test. Fixes flux-framework#5530
This is the same issue as described in #4648, but I've decided to open a new issue instead of reopening that one.
The motivating use case here is the execution of a new Flux instance under the system instance which also emulates a system instance for use as a DAT job. That is, a batch or alloc job would be run as the
fluxuser, configured as a multi-user capable instance, and access given to a subset of users.Users would have to
flux proxyinto the job to interact with it, and this is not possible currently becauseflux proxyresults in theownerattribute of the connector to be set to the current user (as noted in #4648) and thus jobs are submitted withsign-type=none.Additionally, it does seem like a bug that the local connector thinks the instance owner it is connected to is the same uid.
The text was updated successfully, but these errors were encountered: