Getlogin

[psa]

Provide more consistent logging messages so they're easier to parse and log the username from the system if a command isn't being run by the owner or a scheduler user.

Fixes #6773

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• [N/A] Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• [N/A] Changelog entry included if this is a change that can affect users
• [N/A] Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[oliver-sanders]

The resolver code is run by the scheduler (i.e. the server) not the client, so this isn't going to extract the user who actioned the operation, you would need to shift this into the Cylc client code (cylc.flow.network.client).

However, the client cannot be trusted in this situation (because it is being run by a different user), so it is not possible to achieve this (#6773 (comment)).

[oliver-sanders]

I think this PR is effectively equivalent to:

Suggested change

	if user == self.schd.owner:
	log_user = "" # don't log user name if owner
	if user == self.schd.owner or not user:
	user = os.getlogin()

I.E:

• Log the user name if provided with the request.
• Otherwise log the scheduler owner.

[hjoliver]

@psa - Oliver's comment above sounds like we're going to shut this PR down, but after discussing it offline he's suggested changes on the issue to make it acceptable.

• the sudo-user identification bit has to be done client-side, or else this is useless (regardless of perceived security implications)
• the phrasing of the server log message is very important because any user attribution will be perceived as a security issue if the facts behind it don't stack up
  • it should state that the action is being performed by the role user (which is true) and possibly on behalf of the sudo user (because that user is essentially self-identifying in a way that can't be verified).

And (IMO at least) we should document that use of sudo to interact with shared role accounts is common (for many reasons, not just workflows), and if Cylc commands are executed in this way (which Cylc has no control over) then Cylc will log the sudo-user merely as a convenience - strictly speaking this information should not be trusted, but logging the provided information (in the careful way described) does not in any way imply reduced security beyond what you opt into by use of sudo in the first place. For properly secure Cylc-based authorized user attribution, go via the Cylc UI Server (web UI now, hopefully CLI in future too).

[psa]

I'm working on re-writing this based on the feedback in #6773 (comment)

[oliver-sanders]

Send the full message through using the existing auth_user field rather than creating a new behalf_of one.

auth_user = '<actor> (possibly on behalf of <user>)'

That way no changes will be required in cylc/flow/network/resolvers.py to log this and the feature will be fully backwards compatible.

[psa]

@oliver-sanders
I've been poking at this but need help from someone with more py-zmq knowledge.

I was expecting self.socket.get(zmq.PLAIN_USERNAME) in async_request() to achieve this. I've not found a way to get the username on the client side.

Ideas on how I might approach this?

[oliver-sanders]

@psa, ZMQ doesn't come into it, just replace behalf_of with auth_user and supply it with the full text:

Suggested change

	'behalf_of': behalf_of
	'auth_user': f'{actor} (possibly on behalf of {user})'

Where actor is the actual user account (i.e. $USER) and user is the name of the person who is acting via sudo (i.e. $LOGNAME).

[wxtim]

Drafted after nearly 2 months inactivity

[oliver-sanders]

Ping @psa, let us know if you need any assistance to unstick this PR.

[psa]

Ping @psa, let us know if you need any assistance to unstick this PR.

Thanks @oliver-sanders This has ended up on the backburner due to some personal stuff going on right now. I might not get to it until October . But, I've added a reminder in October to make sure that it doesn't get lost.