login(1) traditionally sets a limited set of environment variables at, well, login time. Like
login will typically ask for a password even if one logins as oneself so that here is probably not ideal. Unix systems may have additional or different complications, e.g. if there is PAM
pam_env(8) could add or remove environment variables from what was set by
login. A copy of what
login(1) does could thus create a different environment variable set than an actual login through PAM sets.
Then there are terminals and shells; terminals may or may not launch the subsequent process as a "login" shell. Shells may read different files when flagged as login and may end up with different env variables for login vs. non-login instances. There is existing literature on this topic.
So based on the unix, the login process, local system configuration, what shell the user uses, and local configuration for that shell there may be different environment variables set "by default."
You may be able to get a suitable list of environment variables with a login shell instance:
% export CANARY=tweet
% env -i bash -l -c 'env | grep CANARY'
/Users/jhqdoe/.profile: line 6: set: markdirs: invalid option name
this does clear environment variables from the parent process (
env | grep CANARY would be where your
.profile here is actually for
bash. However, the above may not set necessary variables that the login workflow sets as it does not go through that code. These might be inspected to see what they are with a new login and then to run:
$ env > def
$ env -i bash -l -c 'env > new'
And then to compare the
new files to see how they differ (possibly involving the
diff commands), then possibly updating the
env command to set things that are missed before then doing the login shell.
Another idea is to snapshot the environment and use that as the default.