Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement request - fdesetup authrestart or similar #101

Open
jelockwood opened this issue Jun 5, 2023 · 3 comments
Open

Enhancement request - fdesetup authrestart or similar #101

jelockwood opened this issue Jun 5, 2023 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@jelockwood
Copy link

@Macjutsu
Having managed to get a Mac to upgrade from Big Sur to Ventura via this Super script I have observed that 'normal' behaviour is that it triggered an initial reboot to the FileVault2 login screen. Once that was logged in, the upgrade proceeded correctly.

I believe it might be possible to use the fdesetup authrestart command to pre-authorise the FileVault2 login to skip this step, this would speed up things and avoid the possibility that the user ignores the login screen and the login screen times out and shuts down the Mac.

Would it be possible for you to add using this function?

See the man page in Terminal for fdesetup

@Macjutsu
Copy link
Owner

Macjutsu commented Jun 5, 2023

Two things.

  1. That command requires you pass in the username and password of a FileVault user. So this makes it only usable in the case where super knows the user's password. Thus, not helping with many workflows.
  2. Even if super did know the user's name and password. Any process that that interferes with the update/upgrade restart workflow will break the update/upgrade mechanism and you will be left with a "normal" restart and no update/upgrade. In other words, if fdesetup restarts the Mac then the update/upgrade will not actually commence upon restart.

@Macjutsu Macjutsu closed this as completed Jun 5, 2023
@jelockwood
Copy link
Author

jelockwood commented Dec 4, 2024

@Macjutsu
I am not re-opening this but I have a follow up query.

If SUPER is creating a service account for itself i.e. the 'Super Update Service' account and this account has FileVault i.e. Secure Token/Volume Owner permissions which it does, could you not use this account to do a fdesetup authrestart ?

This would not address issue 2, for this as a precaution you could add a LaunchDaemon which checks after a reboot to see the upgrade failed and if needed turn off/clear the authrestart and do another restart. Or leave it to admins to consider whether this risk is acceptable.

UPDATE
For completeness and clarity, apparently the fdesetup syntax would be -

sudo fdesetup authrestart -delayminutes -1

and would be triggered before the macOS update install command

As a way to pass the password to fdesetup via a script see the following article, this temp file could be in /var/tmp and deleted immediately after the command is executed.

https://www.peachpit.com/articles/article.aspx?p=2300563&seqNum=10#:~:text=When%20you%20run%20the%20fdesetup,in%20system%20memory%20and%20reboots.

The full command would then look something like

sudo fdesetup authrestart -delayminutes -1 -inputplist < /path/to/filename.plist

@Macjutsu Macjutsu added the enhancement New feature or request label Dec 4, 2024
@Macjutsu Macjutsu added this to the Undetermined milestone Dec 4, 2024
@Macjutsu Macjutsu reopened this Dec 4, 2024
@jelockwood
Copy link
Author

@Macjutsu
Some further thoughts on this topic.

I have never (myself) used this authrestart function so I have not seen it in action. However if by telling fdesetup the credentials as suggested for the super account it ends up trying to login after the restart as super then I can see you have correctly set the shell for the super account to /dev/null

This means it will not be able to login as a GUI user as far as I am aware and certain not itself run scripts. It also does not have a user home directory specified.

This might prevent it being useable for this purpose - if so I would not expect you to change the config of this user account and not to create an additional use account and we might have to abandon the idea. I am hoping the Mac will allow using it for the FileVault reboot and authentication but ideally not login as this account to a GUI desktop.

Let me know what your testing shows and we can discuss this further. A possible option would be to have a launchagent which detects a login using this account, turns off authrestart and does another reboot. This should be post update being installed and then leave the Mac at the FileVault login screen ready for the real user i.e. with FileVault still active and ecnrypted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants