Privileges.app and time-limited admin

Privileges is an open source tool from SAP which helps folks manage admin rights for their account. As part of its feature set, it includes an option for time-limited admin using a specific function called Toggle privileges.

However, Toggle privileges’s time-limited admin feature for Privileges is its most misunderstood feature. The reason is that while the ability to set a time limit is only available if you’re using the Toggle privileges function, many users assume that this time-limited admin is available universally to all the functions used to get admin rights using the Privileges app.

It is not. Time limited admin is only available using the Toggle privileges function. If you’re not using the Toggle privileges function, there is no time limitation and you cannot set one from within the Privileges app.

This information is available in the Privileges FAQ:

• Question: By default, is there a time limit on the admin rights granted by Privileges?
• Answer: No. Admin rights are granted until some process (like running Privileges again) takes them away.

• Question: Can I set Privileges to give me administrator rights for a defined amount of time?
• Answer: Yes. You can use the Toggle Privileges option on the dock icon to get admin rights for a set amount of time (the default amount is 20 minutes.)

What does this mean?

1. The only way time-limited admin is currently working on Privileges is by using the Toggle privileges function.
2. If you are clicking on the icon in the dock and not selecting the Toggle privileges function, there’s no time limit.
3. If you’re using the PrivilegesCLI command line tool, there is no time limit.

How long do you have admin if you’re not using the Toggle privileges function? Admin rights are granted until some process (like running Privileges again) takes them away. There’s no time limit.

All of the Privileges management options available for time-limited admin at this time apply only to the Toggle privileges function. If you’re using any of the management settings options listed below, they apply only and exclusively to the Toggle privileges function:

• DockToggleTimeout
• DockToggleMaxTimeout

They will not manage time-limited admin for any of Privileges’ functions outside of using the Toggle privileges function.

What if you want time-limited admin outside of using the Toggle privileges function? You will need to use a separate mechanism. In my case, I usually point folks towards using PrivilegesDemoter:

https://github.com/sgmills/PrivilegesDemoter

This tool uses a separate mechanism for figuring out the timing and then uses the PrivilegesCLI command line tool to take away admin when the time limit set for PrivilegesDemoter expires.

Specifying shell commands to run when opening new Terminal windows from macOS’s Terminal settings

As a follow-up to a previous post, as part of that post I had been running certain shell commands by adding them to a .zshrc file:

• export PS1=”\$ “: Sets the prompt to only display “$” (no quotes) using the PS1 environmental variable.
• unset zle_bracketed_paste: Disable the zsh shell’s bracketed paste feature.

With some additional research, I learned that I could also run these commands using the Run command function which is available in your Terminal settings under the Shell tab.

To replicate what I wanted, I had to enable the Run command option in the Shell tab, then also set Run inside shell. Once those were enabled, I added the following shell commands:

export PS1="\$ " && unset zle_bracketed_paste && clear

• export PS1=”\$ “: Sets the prompt to only display “$” (no quotes) using the PS1 environmental variable.
• unset zle_bracketed_paste: Disable the zsh shell’s bracketed paste feature.
• clear: Removes all contents (including running the commands listed above) from the Terminal window.

The reason why this is nice is that I can now add running these commands to a macOS configuration profile using the CommandString key:

	<key>CommandString</key>
	<string>export PS1="\$ " &amp;&amp; unset zle_bracketed_paste &amp;&amp; clear</string>

view raw

gistfile1.txt

hosted with ❤ by GitHub

To see this used in context in a macOS configuration profile, please see below the jump.

Customizing Terminal behavior for documentation needs

As part of writing documentation today, I was given a script to follow when making some videos as part of the documentation process. The script included the following requirement:

• Prepare the Terminal to not show the hostname or the logged-in user

By default, Terminal in macOS Monterey will show both. How to get rid of this?

Fortunately for me, @scriptingosx had already documented how to do this as part of this post. You can use the PS1 environmental variable to set how your prompt appears in Terminal. After some experimentation, I set the following environmental variable:

PS1="\$ "

To have this prompt appear whenever I opened a new Terminal session, I added the following line to a newly-created .zshrc file in my home folder:

export PS1="\$ "

The .zshrc file is a configuration file for the zsh shell, so adding that and then opening a new Terminal window gave me a prompt which looks like this.

As part of making the videos, I also noticed that when I copied and pasted a command into the Terminal that the pasted text was highlighted automatically. I’d seen this before and ignored it, but I thought it might be an unnecessary distraction for those watching this video later, so I went looking for how to disable it.

After some research, I found that this was zsh’s “bracketed paste” feature, which was introduced as part of zsh 5.1. This feature can be turned off using the following command:

unset zle_bracketed_paste

Adding entries for both the prompt and turning off bracketed paste to my .zshrc file gave me the Terminal behavior I wanted:

export PS1="\$ "
unset zle_bracketed_paste

I also performed additional customization of my Terminal experience, but those modifications were managed using a configuration profile. For more details on that, please see this previous post:

https://derflounder.wordpress.com/2019/12/19/deploying-terminal-profile-settings-using-macos-configuration-profiles/

Removing unwanted Time Machine backups from APFS-formatted Time Machine backup drives on macOS Monterey

I recently needed to prune some Time Machine backups, where I wanted to manually delete some older backups while not deleting everything on the drive. When I researched this, the guidance provided used the procedure described below:

1. Connect your external backup drive to your Mac if needed.
2. Launch the Time Machine app.
3. Use the timeline on the right of the screen or the arrows to navigate to the backup date you want to delete. Alternatively, use the Finder window to navigate to the file or folder you want to delete.
4. After selecting the date or file you want to delete, click the Action (…) button in Finder and choose to either Delete Backup or Delete All Backups of [Your File]

For an HFS+ formatted Time Machine backup drive, this guidance is correct. However, my Time Machine backup drive is APFS formatted. When following this guidance, I ran into the following issue:

1. Connect your external backup drive to your Mac if needed.
2. Launch the Time Machine app.
3. Use the timeline on the right of the screen or the arrows to navigate to the backup date you want to delete. Alternatively, use the Finder window to navigate to the file or folder you want to delete.
4. After selecting the date or file you want to delete, click the Action (…) button in Finder.

With APFS-formatted Time Machine backup drives, only the option to restore files is available. The Delete Backup or Delete All Backups options are not available.

So how can unwanted Time Machine backups be manually deleted? For more details, please see below the jump.

Safari 15.5 embedded content slow to load

As part of the release of Safari 15.5, there seems to be an issue with Safari being able to load embedded content on some websites. One example is the US State Department’s site for reporting a lost or stolen passport:

https://travel.state.gov/content/travel/en/passports/have-passport/lost-stolen.html

This site has embedded content and Safari is very slow to load that site. The behavior seems to be tied to the Hide IP address from trackers setting in Safari’s privacy settings:

 

With that setting enabled, slow website loading:

With that setting disabled, normal website loading:

Discussing standard versus admin rights, hosted by Kandji

Kandji invited me to discuss the topic of whether you should set up users in your work environment with standard user rights or admin user rights. It’s a great topic and was a lot of fun to dig into, so I’m happy to say that they recorded the discussion between me and Steven Vogt. If you’re interested, the discussion is available on YouTube and I’ve linked it below:

profiles command includes client-side rate limitation for certain functions on macOS 12.3

One of the changes brought with macOS 12.3 is that the profiles command line tool now includes a rate limiter for some of its functions:

profiles show

profiles validate

In both cases, running these functions may be limited to once every 23 hours.

For those familiar with rate limitation on the server side, where a server may choose to limit how many calls can be received in a set period from a client, this rate limitation is similar but is set and managed entirely on the client side. This means that there is no bypassing the profiles command’s rate limitation in this case for the Mac in question.

One way this may appear is on Macs which are part of the Automated Device Enrollment program, where the Mac can show its enrollment status by running the following command:

profiles show -type enrollment

view raw

gistfile1.txt

hosted with ❤ by GitHub

In the event that this command errors, the profiles command will block further attempts to display this information for the next 23 hours. In this situation, you may see output like that shown below:

	username@computername ~ % sudo profiles show -type enrollment
	Password:
	Device Enrollment configuration:
	(null)
	username@computername ~ % sudo profiles show -type enrollment
	Error fetching Device Enrollment configuration – Request too soon. Try again later.

view raw

gistfile1.txt

hosted with ❤ by GitHub

At this time, I don’t know where the information which tracks this 23 hour limitation is stored, but I did confirm that it is stored somewhere in the writable portion of the Mac’s boot drive. Wiping the Mac’s boot drive, via a disk wipe and OS reinstall or via Erase All Contents and Settings, will remove whatever is tracking and enforcing the 23 hour limitation.

Update – 4-22-2022:

It looks like the file which tracks this information is stored in the following location:

/private/var/db/ConfigurationProfiles/Settings/.profilesFetchTimerCheck

This file is protected by SIP. Thanks to zolotkey in the comments!

Also, in the original version of this post, I had made a mistake and conflated the functions of the following commands:

• profiles renew -type enrollment
• profiles show -type enrollment

The profiles renew -type enrollment command can be used to enroll or re-enroll a Mac which is part of the Automated Device Enrollment program with the MDM server that ADE associates the Mac with. To the best of my knowledge, the renew function of the profiles command does not have a client side rate limitation on macOS 12.3. Thanks also to Richard in the comments for catching my mistake and letting me know about it.

Using macOS installer disk images to boot VMware Fusion virtual machines to macOS Recovery

Booting a VMware Fusion virtual machine to the macOS Recovery environment can be challenging, as Fusion uses Command-R as a keyboard shortcut for restoring snapshots.

This is the same keyboard shortcut as booting to macOS Recovery for Intel Macs so if you’re not very fast, or you don’t have the virtual machine window selected correctly, you may be looking at an unwanted request to restore a snapshot instead of macOS Recovery.

Fortunately, there’s a workaround for this behavior which will reliably get you into macOS Recovery. For more details, please see below the jump.

Using custom variables in an AutoPkg recipe to set version information

As part of a recent task to build an AutoPkg recipe which creates an installer package for a screen saver, I ran into an issue. The vendor, for reasons that no doubt make sense to them, split the version information for the screen saver across two separate keys:

• Major part of the version number: Stored in the CFBundleShortVersionString key of the screen saver’s Info.plist file
• Minor part of the version number: Stored in the CFBundleVersion key of the screen saver’s Info.plist file

What this meant is that for version 1.4 of the screen saver, the version information was stored as follows:

• CFBundleShortVersionString key: 1
• CFBundleVersion key: 4

Getting this information was not the problem. AutoPkg includes a PlistReader processor which allows multiple values to be read from one plist file, so I used it as shown below to read the CFBundleShortVersionString key’s and the CFBundleVersion key’s values and store them in the following variables:

• CFBundleVersion key: minor_version
• CFBundleShortVersionString: major_version

	<dict>
	<key>Arguments</key>
	<dict>
	<key>info_path</key>
	<string>%pathname%/Carousel Cloud.saver/Contents/Info.plist</string>
	<key>plist_keys</key>
	<dict>
	<key>CFBundleVersion</key>
	<string>minor_version</string>
	<key>CFBundleShortVersionString</key>
	<string>major_version</string>
	</dict>
	</dict>
	<key>Processor</key>
	<string>PlistReader</string>
	</dict>

view raw

gistfile1.txt

hosted with ❤ by GitHub

So now I had the version info (in separate pieces) and now I needed to put them together. The problem I was seeing was that my usual solution, AutoPkg’s Versioner processor is set up to read one value from a plist file. I had two values and neither were in a plist file.

Fortunately, there are multiple ways to solve this problem. The first I thought of was to build a new plist as part of the recipe’s run and put the version information in. The workflow works like this:

1. Use the PlistReader processor to read the desired information.
2. Use the FileCreator processor processor to create a new plist file with the version information formatted as needed.
3. Use the PlistReader processor to read the version information out of the newly-created plist file.

	<dict>
	<key>Arguments</key>
	<dict>
	<key>info_path</key>
	<string>%pathname%/Carousel Cloud.saver/Contents/Info.plist</string>
	<key>plist_keys</key>
	<dict>
	<key>CFBundleVersion</key>
	<string>minor_version</string>
	<key>CFBundleShortVersionString</key>
	<string>major_version</string>
	</dict>
	</dict>
	<key>Processor</key>
	<string>PlistReader</string>
	</dict>
	<dict>
	<key>Processor</key>
	<string>FileCreator</string>
	<key>Arguments</key>
	<dict>
	<key>file_path</key>
	<string>%RECIPE_CACHE_DIR%/com.companyname.carouselcloudscreensaver.plist</string>
	<key>file_mode</key>
	<string>0755</string>
	<key>file_content</key>
	<string>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
	&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
	&lt;plist version="1.0"&gt;
	&lt;dict&gt;
	&lt;key&gt;complete_version&lt;/key&gt;
	&lt;string&gt;%major_version%.%minor_version%&lt;/string&gt;
	&lt;/dict&gt;
	&lt;/plist&gt;
	</string>
	</dict>
	</dict>
	<dict>
	<key>Arguments</key>
	<dict>
	<key>info_path</key>
	<string>%RECIPE_CACHE_DIR%/com.companyname.carouselcloudscreensaver.plist</string>
	<key>plist_keys</key>
	<dict>
	<key>complete_version</key>
	<string>version</string>
	</dict>
	</dict>
	<key>Processor</key>
	<string>PlistReader</string>
	</dict>

view raw

gistfile1.txt

hosted with ❤ by GitHub

This approach works, but now you have a plist file to clean up later. Another approach is to use custom variable assigning as part of another AutoPkg processor’s run. In this case, you’re using an AutoPkg processor and adding a separate argument which is probably unrelated to the other work the processor is doing, but does the value assignment work you couldn’t accomplish otherwise.

A pretty safe processor to use for this is the EndOfCheckPhase processor. The reason is that by itself, the EndOfCheckPhase processor takes no actions. Instead, it’s used as a marker in AutoPkg recipes to tell AutoPkg to stop checking for new information as part of a recipe’s run. However, even though the EndOfCheckPhase processor doesn’t take actions and doesn’t by default include Arguments values, AutoPkg will still process Arguments values if they’re defined for the EndOfCheckPhase processor. That allows custom variables to be set with values that you couldn’t otherwise set and pass them to AutoPkg. The workflow in this case looks like this:

1. Add the EndOfCheckPhase processor to the very end of the recipe.
2. Perform the desired variable assignment as an Arguments value

The reason to add it to the end is to make sure that all of the other tasks the recipe is performing are completed by the time this processor runs.

In this case, I used this method with the the EndOfCheckPhase processor in the screen saver’s .download recipe to assign the version variable to use the values of the major_version and minor_version variables, separated by a period.

	<dict>
	<key>Processor</key>
	<string>EndOfCheckPhase</string>
	<key>Arguments</key>
	<dict>
	<key>version</key>
	<string>%major_version%.%minor_version%</string>
	</dict>
	</dict>

view raw

gistfile1.txt

hosted with ❤ by GitHub

The result for the latest version of the screen saver software is that the version variable is assigned the following value:

'version': '1.4'

view raw

gistfile1.txt

hosted with ❤ by GitHub

I’ve posted the recipes which use this technique for setting version information to GitHub. They’re available via the link below:

https://github.com/autopkg/rtrouton-recipes/tree/master/CarouselCloudScreenSaver

Jamf Pro Server software no longer supported on macOS as of Jamf Pro 10.37.0

To follow up on my earlier posts on the Jamf Pro Server Installer for macOS being retired, Jamf has added the following to the Deprecations and Removals section of the Jamf Pro 10.36.0 release notes:

Support Ending for Hosting Jamf Pro Server on macOS—Starting with the release of Jamf Pro 10.37.0, hosting the Jamf Pro server on macOS will no longer be supported. Mac computers with Apple silicon are not supported by the Jamf Pro Installer for macOS. In addition, the Jamf Pro Installer for macOS will not be available to download. The Jamf Pro utilities that were included in the Jamf Pro Installer for macOS—Composer, Jamf Admin, Jamf Recon, and Jamf Remote—will be made available as a separate download.

If you want to migrate your Jamf Pro server from macOS to Jamf Cloud, contact Jamf Support. If you want to keep your server on premise, you can migrate your Jamf Pro server to one of the following servers: Red Hat Enterprise Linux, Ubuntu, or Windows. For more information, see the Migrating to Another Server article.

For those folks who are running on-premise Jamf Pro servers on Macs, I strongly recommend contacting Jamf Support right now and plan a migration if you haven’t already. As of February 21st, 2022, Jamf’s published support for running Jamf Pro includes the following OS, database and Java versions:

	Recommended Configuration:
	Operating Systems:
	Windows Server 2019
	Ubuntu Server 20.04 LTS
	Red Hat Enterprise Linux 7.x
	Database software versions:
	MySQL 8.0.27 – InnoDB
	Amazon Aurora (MySQL 5.7 compatible)
	MySQL 5.7.36 or later – InnoDB
	Java version:
	OpenJDK 11
	Minimum Supported:
	Operating Systems:
	Windows Server 2016
	Windows Server 2012 R2
	Ubuntu Server 18.04 LTS
	macOS 10.15 (Support for the Jamf Pro Installer for macOS and hosting Jamf Pro server on macOS will be discontinued with the release of Jamf Pro 10.37.0.)
	macOS 10.14 (Support for the Jamf Pro Installer for macOS and hosting Jamf Pro server on macOS will be discontinued with the release of Jamf Pro 10.37.0.)
	Database software versions:
	MySQL 5.7.36 – InnoDB
	MySQL 5.7.8 on Amazon RDS – InnoDB
	Java version:
	Oracle Java 11

view raw

gistfile1.txt

hosted with ❤ by GitHub