Skip to content
However, I just tried:
(a) it prompts for permission (no permission request without it), and
(b) it sets permissions on NEW entries properly, but it doesn't actually *change* an existing keychain entry
Returning username/password from pre-connect script
Got a problem with Viscosity or need help? Ask here!
Hi,
We have a pre-connect script which retrieves the username/password needed to connect to our OpenVPN through some other means. So far we've been using "security add-generic-password" to set it within the pre-connect script, so by the time Viscosity needs it, it's already in the keychain, but due to what appears to be Apple's bug[1], Viscosity has to pop-up a permissions dialog whenever we refresh the credentials (which is very often).
Technically, after Viscosity's keychain permission confirmation, the following change happens in the keychain:
[1] http://www.openradar.me/29144482
We have a pre-connect script which retrieves the username/password needed to connect to our OpenVPN through some other means. So far we've been using "security add-generic-password" to set it within the pre-connect script, so by the time Viscosity needs it, it's already in the keychain, but due to what appears to be Apple's bug[1], Viscosity has to pop-up a permissions dialog whenever we refresh the credentials (which is very often).
Technically, after Viscosity's keychain permission confirmation, the following change happens in the keychain:
Code: Select all
My question - is there a more proper way to return username/password to Viscosity, so then Viscosity would perform the keychain manipulation and the teamid would be correctly assigned? (The "security add-generic-password" command doesn't provide a way to specify a "teamid".) entry 3:
authorizations (1): partition_id
don't-require-password
- description: apple-tool:
+ description: apple-tool:, teamid:34XR7GXFPX
applications: <null>
[1] http://www.openradar.me/29144482
Hi ikonst,
I'm afraid we don't currently have any alternative options available. We're investigating the possibility of a Before-Connect script returning a username and password, but we're not entirely sure of the details at this stage and so we can't make any promises regarding it's inclusion in an update.
Apple have been making a number of security changes to the Keychain since the XARA attacks, and it's possible resetting the permissions in such a way may be a continuation of those changes (as many such attacks relied on permissions inheritance). If the passwords are one-time temporary passwords you could potentially try changing the permissions on the saved password in Keychain Access to "Allow all applications to access this item" and see if the individual app permissions are still reset.
Cheers,
James
I'm afraid we don't currently have any alternative options available. We're investigating the possibility of a Before-Connect script returning a username and password, but we're not entirely sure of the details at this stage and so we can't make any promises regarding it's inclusion in an update.
Apple have been making a number of security changes to the Keychain since the XARA attacks, and it's possible resetting the permissions in such a way may be a continuation of those changes (as many such attacks relied on permissions inheritance). If the passwords are one-time temporary passwords you could potentially try changing the permissions on the saved password in Keychain Access to "Allow all applications to access this item" and see if the individual app permissions are still reset.
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
James wrote:If the passwords are one-time temporary passwords you could potentially try changing the permissions on the saved password in Keychain Access to "Allow all applications to access this item" and see if the individual app permissions are still reset.That's a valid point for OTPs.
However, I just tried:
Code: Select all
The -A option is documented as "Allow any application to access this item without warning (insecure, not recommended!)" but:security add-generic-password -s 'Viscosity/1/ovpn' -a 'username' -p 'REDACTED' -U -A
(a) it prompts for permission (no permission request without it), and
(b) it sets permissions on NEW entries properly, but it doesn't actually *change* an existing keychain entry
3 posts
Page 1 of 1