Privileges 2.4 Public Beta

[mthielemann]

Here is a first preview of the upcoming version 2.4 of Privileges.

What's new?

• If you've configured Privileges with a maximum expiration interval, there is now a new key MaxIntervalInitial that allows you to define the initial interval to use. So you could now define a maximum interval of 60 minutes and set the initial interval to 10 minutes. This will only work as long as the user has not selected an expiration interval. So it's good for the initial setup of a Mac.

• Unsent syslog or webhook events can now be queued. So if a user does not have an internet connection, these events are not lost as in previous versions of Privileges, but are queued. To enable event queueing, set the new QueueUnsentEvents key to true. Additionally, you can configure the maximum number of events that should be queued by using the QueuedEventsMax key. Here's how event queueing works:

  • If an event (syslog or webhook) cannot be sent, it will be stored locally in /Library/Application Support/Privileges/QueuedEvents.plist.
  • The next time any user changes their admin rights via Privileges, an attempt will be made to resend the queued events.
  • If, due to configuration changes, webhook and syslog events are mixed in the event queue, only the events that match the currently configured logging type are resent. Events of a different logging type are discarded.
  • We make sure that the events are sent in the correct order. So the current event will be sent after the queued events.
  • Webhook events have a new delayed key, that is set to true for queued events. This makes it relatively easy for the receiver to identify these events.
  • Events that still could not be sent are returned to the event queue. If the number of unsent events is greater than QueuedEventsMax, the oldest events are discarded. Setting QueuedEventsMax to 0 means that an unlimited number of events will be queued (not recommended).

• Fixed an issue where a misconfiguration of the RevokeAtLoginExcludedUsers could cause unwanted application behavior.

Please play around with the new features and open an issue if you have any feedback. Thanks and happy testing!

Privileges_2.4.0b2045.pkg.zip

[disenchant]

@mthielemann

The next time any user changes their admin rights via Privileges, an attempt will be made to resend the queued events.

What's the reason for waiting till the next privilege adjustment is made instead of checking if the queued events can be sent out in a regular interval? For example if a user elevates privileges while offline, and then while back online a week later, we would have to wait for a full week to get the queued event.

[mthielemann]

It's for efficiency. Instead of endlessly trying to resend the event, we just try it the next time we need to send an event anyway. Why is it important for you to get these old events as soon as possible?

[disenchant]

Thank you for the feedback. My example using one week was likely too short. Some users elevate their privileges only once a month or even less frequently. This means that any statistics, monitoring, or other data derived from these events could be significantly delayed. I strongly suggest re-trying to send the events at least every few hours. This should have a negligible impact on efficiency.

[mthielemann]

@disenchant Thank you. I wasn't aware of a scenario where people only use the app once a month or less. Maybe we can add an option to allow admins to enable some kind of active retry. That way we could have the current behavior as the default and have an option for environments with special requirements.

[disenchant]

Sounds like a plan, thanks for considering it and keep up the great work 💪

[mthielemann]

Here's a new build for testing which contains the following changes:

• If QueueUnsentEvents is enabled, the PrivilegesAgent not only tries to resend queued events at the next privilege change but also at different intervals. If an event fails to send, the app retries after about 5, 15, 30, and 60 minutes, and then every other hour.
• A new configuration key RequireBiometricAuthentication has been added. If RequireAuthentication is enabled, this new key can be used to force biometric authentication. If Touch ID is configured, the user can only authenticate using Touch ID and cannot use a username and password as a fallback. If the machine does not support biometric authentication or is not configured for it, the user will still be asked for a username and password.

Please play around with the new features and open an issue if you have any feedback. Thanks and happy testing!

Privileges_2.4.0b2057.pkg.zip