An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Permissions Repair in El Cap
#38646 02/04/16 11:18 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
A line of discussion in another thread got me wondering if I had wreaked any havoc by running SIP-less, so I decided to see what repairing permissions would tell me.

Quote:
Artie's-MacBook-Pro:~ artie$ sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
Password:
User differs on "Library/Bundles", should be 0, user is 501.
Group differs on "Library/Bundles", should be 0, group is 20.
Repaired "Library/Bundles".
User differs on "private/var/db/displaypolicyd", should be 0, user is 244.
Group differs on "private/var/db/displaypolicyd", should be 0, group is 244.
Repaired "private/var/db/displaypolicyd".
Artie's-MacBook-Pro:~ artie$

The errors didn't recur in a second run, but the second one recurred after a restart, suggesting that it's just another Apple "will-o'-the-wisp".

The non-recurrence of first one has got me wondering, though...

On the one hand, Apple tells us

Originally Posted By: Apple
Beginning with OS X El Capitan, system file permissions are automatically protected. It's no longer necessary to verify or repair permissions with Disk Utility. (Emphasis added)

but on the other hand, they tell us

Originally Posted By: Apple
Paths and applications protected by System Integrity Protection include:
• /System
• /usr
• /bin
• /sbin
• Apps that are pre-installed with OS X
Paths and applications that third-party apps and installers can write to include:
• /Applications
• /Library
• /usr/local

so there's an awful lot of unprotected territory in OS X, the location of my first permissions error included.

Which leads me to wonder whether Apple has dropped the ball or simply told us "Yeah, we set those permissions, but they're not really important"?

Hmmm...


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permissions Repair in El Cap
artie505 #38650 02/04/16 06:06 PM
Joined: Aug 2009
Likes: 16
Moderator
Offline
Moderator

Joined: Aug 2009
Likes: 16
Permission repair has never worked on applications unless the application installer stored a file containing the "correct" permissions. Applications installed by drag and drop have never done that and all App Store apps encapsulated and are not "installers" per se.. It's is not so much Apple has dropped the ball as the ball is no longer used in the game. No big loss really.


If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Permissions Repair in El Cap
joemikeb #38652 02/04/16 07:23 PM
Banned
Offline
Banned

Joined: Nov 2015
I still will continue to use Onyx for Repairing Permissions, no matter what Apple has (or has not) done regarding the Repairing of Permissions. That venerable product has other useful tasks it can perform.

Re: Permissions Repair in El Cap
joemikeb #38655 02/04/16 09:05 PM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Originally Posted By: joemikeb
Permission repair has never worked on applications unless the application installer stored a file containing the "correct" permissions. Applications installed by drag and drop have never done that and all App Store apps encapsulated and are not "installers" per se..

That's old hat, and I'm not sure why you focused on applications, anyhow; I had /Library, the home of my error, in mind.

Doesn't it seem like correct permissions ought to be important there?


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permissions Repair in El Cap
artie505 #38701 02/06/16 08:53 PM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Nobody?


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permissions Repair in El Cap
artie505 #38787 02/11/16 02:27 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: artie505
Nobody?

The permissions are a part of the installer. When the installer installs files and folders, it refers to the receipts portion of the installer to determine what ownerships and permissions to set on the files and folders as it installs them. (this IS the indication of correctness in the installer, there is no other copy)

After the installation finishes, the installer is copied to the receipts folder, but without the data files themselves. So only the receipts remain. This allows a permissions repair later to go back and "fix" any permissions that have been altered since installation.

If the permissions were described wrong in the installer in the first place, they'll get installed wrong, and the receipt left behind will therefore also be wrong, and won't help you to "fix" it later.


I work for the Department of Redundancy Department
Re: Permissions Repair in El Cap
Virtual1 #38794 02/11/16 07:05 PM
Joined: Aug 2009
Likes: 16
Moderator
Offline
Moderator

Joined: Aug 2009
Likes: 16
What V1 said and in addition…
  • permission repair may not work if the applications has been moved from the original location to another folder, especially if that folder is under a user's home folder.
  • ACLs (Access Control Lists) override the file permissions and are not changed by permission repair. Many of the false positives in Permission Repair were/are the result of ACLs set by the developer even in some cases where Apple was/is the developer. NOTE: changing the ACL can break an application or applications and is the likely explanation for what you reported in the original post in this thread.
  • Although iOS runs on the same Darwin kernel as OS X there has never been a permission repair utility in iOS nor has one ever been needed.
IMO the reason permission repair was necessary and included in previous versions of OS X was because of poorly designed, written, and tested installer scripts from developers. Sandboxing of apps in iOS and OS X together with SIP (System, Integrity Protection) of the OS X kernel from non-sandboxed apps have made permission repair unnecessary and obsolete (unless you choose to disable SIP — but at that point you are on your own).


If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Permissions Repair in El Cap
joemikeb #38822 02/12/16 08:19 PM
Banned
Offline
Banned

Joined: Nov 2015
I will be posting something "related" to this, about Onyx, on another thread. But, suffice it to say that Onyx "saved my bacon" with an issue I had earlier today with booting into Safe Mode on my Mac Mini. Surprisingly, that issue did not happen on my MacBook Air (I run OS 10.11.3 on both machines, and just about all the same software).

Last edited by honestone; 02/13/16 01:17 AM.
Re: Permissions Repair in El Cap
joemikeb #38842 02/13/16 10:43 AM
Joined: Aug 2009
Likes: 15
OP Online

Joined: Aug 2009
Likes: 15
Originally Posted By: joemikeb
IMO the reason permission repair was necessary and included in previous versions of OS X was because of poorly designed, written, and tested installer scripts from developers. Sandboxing of apps in iOS and OS X together with SIP (System, Integrity Protection) of the OS X kernel from non-sandboxed apps have made permission repair unnecessary and obsolete (unless you choose to disable SIP — but at that point you are on your own).

I'm either not making my point or not understanding your and V1's responses in relation thereto.

Originally Posted By: joemikeb
NOTE: changing the ACL can break an application or applications and is the likely explanation for what you reported in the original post in this thread.

That sounds like it's on target as respects the second error I reported...

Quote:
User differs on "private/var/db/displaypolicyd", should be 0, user is 244.
Group differs on "private/var/db/displaypolicyd", should be 0, group is 244.
Repaired "private/var/db/displaypolicyd".

because the "repaired" item recurs after restarting,

but the first one, which has never recurred,

Quote:
User differs on "Library/Bundles", should be 0, user is 501.
Group differs on "Library/Bundles", should be 0, group is 20.
Repaired "Library/Bundles".

doesn't seem to fit that mold, and I can't begin to guess how it arose; it's certainly not an area of OS X that I've ever touched on my own.

/Library isn't protected by SIP or anything else and can be written to indiscriminately, and permissions in that area are, therefore, vulnerable, but in removing permission repair functionality Apple has told us to ignore the vulnerability.

Unless I've totally missed something critical, that doesn't make any sense to me!


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.026s Queries: 32 (0.021s) Memory: 0.6159 MB (Peak: 0.7046 MB) Data Comp: Zlib Server Time: 2024-03-29 11:13:36 UTC
Valid HTML 5 and Valid CSS