Investigate better "forced logout" methods

[gregneagle]

The current method logouthelper uses to forcibly logout users was developed in mid-2011 and is a bit of a nasty hack.

Investigate the use of macOS 10.11+ launchctl methods to do this "better":

launchctl reboot userspace
launchctl bootout gui/<uidNumber>
sudo -u <user> launchctl reboot logout

[gregneagle]

To test: how do these work with machines set to autologin into a specific account at boot? These would be a poor replacement for the current method if all users sessions were logged out, but then the autologin user was logged back in.

[SuperSpyTX]

The current method that I briefly observed in the code (kill all loginwindow processes) seems to break Kerberos authenticated clients, as the login shell won't ever start back after login (iTerm / Terminal doesn't start login shell, immediately process completed), even if the kerberos ticket files in /tmp are deleted. The solution to this problem was rebooting the machine, sometimes forcing power off and on.

I tried to investigate forced logout options for idle / inactive users on a pool of mac machines after I grew concerned about the machines constantly rebooting and potential HDD wear, and, well my results were rather unsuccessful so far.

Tested with macOS High Sierra 10.13.4

1. kill -9 user login window. Processes were still left running by the same user, and Kerberos would be broken.

2. launchctl bootout gui/$(id -u <username>) and user/ did not seem to not kill all the running processes, I had to use a separate command to kill all the users processes, and even after that still left me with a cfprefsd process.

Edit: I believe even after clearing /tmp with old kerberos tickets and testing both of the logout methods above, Kerberos would still eventually (multiple logouts and users) break with malloc: out of memory error from kinit and related commands.

I will have to do more testing with those commands you have posted.

[gregneagle]

I personally tend to use forced_update_ only for security/OS updates, so there's almost certainly going to be a restart anyway.

One could argue that instead of doing all this stuff, just set a flag to install updates at boot and force a restart. That might be a good approach except for machines encrypted with Filevault...

[gregneagle]

launchctl reboot userspace appears to log right back into a configured autologin account.

sudo -u <user> launchctl reboot logout does as well.

And so does launchctl bootout gui/<uidNumber>.

(Of course a full reboot would also have this issue.)

[gregneagle]

And now I test kill -9 <pid_of_loginwindow> and see the same behavior. We need not worry about this, then, since the behavior is unchanged.

We probably should document this behavior though -- that forced logouts do not work as expected/desired if an autologin user is configured.