Skip to main content
Corrected “us” to “is”.
Source Link

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that usis not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that us not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that is not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

Tweeted twitter.com/askdifferent/status/927518244608659456
Removed UPDATE/EDIT and moved to comment as recommended by local netizen.
Source Link

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that us not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

EDIT: issue resolved. I eventually tracked the issue down to an issue whereby the extended attributes (xattrib) of the copied Keychain.menu item had were not identical to what they had originally been. Once I rectified that, the issue disappeared and the “crude method” does, indeed, work as advertised.

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that us not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

EDIT: issue resolved. I eventually tracked the issue down to an issue whereby the extended attributes (xattrib) of the copied Keychain.menu item had were not identical to what they had originally been. Once I rectified that, the issue disappeared and the “crude method” does, indeed, work as advertised.

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that us not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

Added edit to explain that the issue was found to be related to extended attributes (xattrib) and once resolved, everything works as desired.
Source Link

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that us not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

EDIT: issue resolved. I eventually tracked the issue down to an issue whereby the extended attributes (xattrib) of the copied Keychain.menu item had were not identical to what they had originally been. Once I rectified that, the issue disappeared and the “crude method” does, indeed, work as advertised.

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that us not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

Like others I have been mourning the loss of the Keychain Access menubar item. In the thread I linked to, the OP him-or-herself proposes a self-described “crude workaround” that involves copying the keychain.menu item from within /Applications/Utilities/Keychain Access.app/Contents/Resources of a machine running macOS 10.12, copying it over, and running it. This, it is claimed, reinstates the menu bar item.

I held out trying this until the release of 10.13.1 in the hope that the disappearance of the Keychain Access menubar item was an oversight Apple would promptly rectify. Unfortunately that us not the case and as of yesterday's update the item is still missing, so I guess it's a deliberate decision on Apple's part.

Unfortunately, the method proposed, as stated in that thread, does not work.

When I read the proposed solution it was quite clear to me that it would entail disabling System Integrity Protection (SIP), as Keychain Access is rightly protected as it is is a key node on many paths of trust through the system. So this I did: I disabled SIP, copied over the menu item from an older system, and ran it, hoping for it to appear in the menu bar. Unfortunately this is not the case: it gets launched, but nothing else happens. I eventually tracked down this entry in the system log, despite SIP being disabled and reported as such by csrutil status:

Sandbox: mdwrite(507) System Policy: allow file-write-xattr/Applications/Utilities/KeychainAccess.app/Contents/Resources/Keychain.menu 
Violation:       System Policy: allow file-write-xattr /Applications/Utilities/Keychain Access.app/Contents/Resources/Keychain.menu 
MetaData: {"build":"Mac OS X 10.13.1 (17B48)","action":"allow","target":["Applications","Utilities","Keychain Access.app","Contents","Resources","Keychain.menu"],"hardware":"Mac","platform_binary":"yes","profile":"unknown","process":"mdwrite","op":"file-write-xattr"}

At this point I'm a bit at a loss to why SIP is still preventing this executable from running despite it allegedly being disabled, and how I can actually cause it to run. I'm clearly a bit out of my depth.

EDIT: issue resolved. I eventually tracked the issue down to an issue whereby the extended attributes (xattrib) of the copied Keychain.menu item had were not identical to what they had originally been. Once I rectified that, the issue disappeared and the “crude method” does, indeed, work as advertised.

edited title
Link
grg
  • 205.6k
  • 45
  • 364
  • 496
Loading
Removed unnecessary commentary.
Source Link
Monomeeth
  • 65k
  • 14
  • 152
  • 190
Loading
Source Link
Loading