the flux user cannot run jobs when flux-accounting is installed and flux is not in the database

[garlick]

Problem: It seems like the flux(instance owner) user should always be allowed to run, to support "system jobs". (@jameshcorbett has a use case for this now). But flux-accounting prevents this unless the flux user is in the database.

I was thinking maybe flux-core could do something to ensure this always works but I'm not sure how we would do that generally - it might need to go in flux-accounting. But anyway, maybe others have some ideas.

[grondo]

I can't think of a way this could be done in flux-core alone, either, since the job-manager can't know why the job was rejected by a plugin , and we don't want to accidentally allow jobs rejected for other reasons.

I'm going to move this issue to flux-accounting. The mf_priority plugin can add a check to allow the current uid even if it doesn't have a current entry in the association. Or, perhaps a default bank can always be added for the instance owner. I'll allow @cmoussa1 to decide on the correct approach here.

[cmoussa1]

Sounds good, I'm happy to take a look at this. To keep the logic the same in regards to other associations in the flux-accounting DB, perhaps we can just automatically add a default flux user and flux bank upon DB creation?

[grondo]

Sounds like a good idea to me! You should be able to check the security.owner broker attribute, or just use getuid(2) to get the userid of the instance owner (it need not always be user flux).

[cmoussa1]

Cool, thanks! I think I'm able to get the userid no problem by just checking the security.broker attribute. Is there a way to fetch the name of the instance owner, then, if it is not always flux?

[cmoussa1]

Oh, duh. I just realized if I have the UID I can just look up the corresponding username:

pwd.getpwuid(int(userid))

[grondo]

Hm, you may have to use getpwuid_r(3), but let me see if somewhere else in flux already has this information.