Without knowing your effective ansible config — i.e. the ansible.cfg it’s using, the environment variables that can override those settings, and command line parameters that can override everything else — it’s impossible to say. Factors include “become”, “become-user”, “become-method”, “ask-pass”, “ask-become-pass”, and probably more.
Are you gathering facts? Ansible does gather facts by default, so if you aren’t turning that off somewhere, you can use the variables containing user related facts. For example:
$ ansible localhost -m gather_facts | grep ansible_user
"ansible_user_dir": "/home/utoddl",
"ansible_user_gecos": "Todd Lewis",
"ansible_user_gid": 12428,
"ansible_user_id": "utoddl",
"ansible_user_shell": "/bin/bash",
"ansible_user_uid": 12428,
"ansible_userspace_architecture": "x86_64",
"ansible_userspace_bits": "64",
Not an Ansible thing, but: Do Not Use “who am i” for this. That’s the same a “who -m”, which shows you the user associated with the stdin stream, but only if that user is logged in AND only if the stdin stream exists and has an associated user. There’s a whole lot of subtle going on there that we don’t want to get into in an Ansible forum. The reason your “su -” followed by “who am i” is showing your id rather than root is (probably) because it’s your id associated with the tty you logged into. But that’s going to be different for Ansible, depending on how your controller connects to the target hosts, including localhost.
I gave you the python code yesterday. It’s dead simple:
import os
import pwd
userid = pwd.getpwuid(os.getuid())[0]
But if you’re gathering facts, just use the ansible_user_id variable.
If that’s “root”, and that appears to be the case, then you’ll need to understand how your controller is connecting to the target hosts. My guess is you’ll eventually need to pass the invoking user’s id as an extra variable (“-e invoking_user=${USER}”) when invoking ansible-playbook. Maybe consider a wrapper script?