Request requires owner credentials

[wkharold]

I've built flux-core with flux-security (--with-flux-security) and userid is included in the allowed-users list in the imp.toml exec table.

Running through the workflow examples everything worked as expected I ran the hierarchical launching scripts. When it tried to do a flux queue drain I get the message

flux-queue: drain: Request requires owner credentials

Do I need to build flux-sched with flux-security as well, or is there something else going on?

Note that the example works fine if I kick it off as flux, i.e., sudo -u flux ./parent.sh

[garlick]

Working as designed? This is a privileged command that only the "instance owner" (user running flux brokers) is allowed to run, or root if you have this configured:

[access]
allow-root-owner = true

The scheduler doesn't require --with-flux-security, and the impl.toml just allows the instance owner userid to run the privileged IMP (to launch work as other users), so not relevant here.

[wkharold]

Awesome. Thanks for the explanation!

[grondo]

The imp.toml allowed-users list should only include the username which is running the Flux system instance, i.e. what we tend to call the system instance owner (typically the flux user). This allows user flux to execute the setuid flux-imp when launching multi user jobs and the IMP transitions credentials to run the job as the actual job userid.

This allows all the privileged code in Flux to be isolated in the flux-imp helper executable.

It is not necessary to add all users that should be allowed to run jobs to the allowed-users list, since only the instance owner needs to be able to run flux-imp. I apologize for the confusion.

Hope this helps, and let us know if you think the documentation needs to be improved to be more clear!

(I see @garlick already addressed the separate issue of permissions for administrative commands in a Flux instance. Many of the workflow examples assume a "single user instance" where the user running Flux is the same as the user running jobs, so some commands may not work as described in a system instance)

[garlick]

Also, I'm not sure how that hierarchical launch example has anything to do with workflows. Looks like it starts 3 flux instances allocated one core each, and runs 750 sleep 0 jobs in each instance.

A more modern way of doing that would be to launch 3 batch jobs using flux mini batch and then have the batch script run flux mini submit --cc=1-750 sleep 0 (--cc is much more efficient than running flux mini submit iteratively)

We probably need to revisit those examples.

[wkharold]

Cool. I only just started playing with the various flux mini commands. I love that you can do a flux mini alloc to get your own private Idaho where you can do flux resource list and just see your resources and then further subdivide those resources if you want to.