Toggle sidebar Toggle sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

How often do you repair permissions?

How Often Do You Repair Permissions

  • Never

    Votes: 20 18.5%

  • Daily

    Votes: 4 3.7%

  • Weekly

    Votes: 16 14.8%

  • Bi-Weekly

    Votes: 2 1.9%

  • Monthly

    Votes: 23 21.3%

  • Very Rarely

    Votes: 43 39.8%
  • Total voters
    108
SC68Cal said:
Would someone start a new thread? We should get a new thread title to attract more people and warn them about this.
Click to expand...

LOLz someone's on a rampage! 😛

Yeah, that thread's been done before. And count me in continual kvetching that I wish OS X was set up to create an admin account separately by default and discourage the principle user from being admin-all-the-time.
 
mkrishnan said:
LOLz someone's on a rampage! 😛
Click to expand...

Let's hope I don't get sent to the time out corner for a few weeks like last time 🙄

Yeah, that thread's been done before. And count me in continual kvetching that I wish OS X was set up to create an admin account separately by default and discourage the principle user from being admin-all-the-time.
Click to expand...

That would take care of lots of problems, I think.
 
SC68Cal said:
Let's hope I don't get sent to the time out corner for a few weeks like last time 🙄

That would take care of lots of problems, I think.
Click to expand...

I don't run as admin either but I actually only change this about a month ago, would there be any residual areas where my account is still an admin, basically all i did was create a separate admin account and deselected the option "Allow user to administer this computer"

I would've done it straight off if i realised at the time the problems and the exact type of account i was creating.

I plan on doing an erase and install with Leopard and will get this setting correct right off the bat.
 
xUKHCx said:
I don't run as admin either but I actually only change this about a month ago, would there be any residual areas where my account is still an admin, basically all i did was create a separate admin account and deselected the option "Allow user to administer this computer"
Click to expand...

There, you're done. You're no longer part of the admin group. You can verify by going to terminal and typing in id.

So for example, this is an admin account id output
Code: 
 admin$ id
uid=501(admin) gid=501(admin) groups=501(admin), 81(appserveradm), 79(appserverusr), 80(admin)

This is a standard user
Code: 
uid=502(user) gid=502(user) groups=502(user)
 
xUKHCx said:
I don't run as admin either but I actually only change this about a month ago, would there be any residual areas where my account is still an admin, basically all i did was create a separate admin account and deselected the option "Allow user to administer this computer"
Click to expand...

I don't think so... applications you installed will still belong to you (if you look at their ownership properties in /applications), but I'm not sure it matters from a security standpoint, because you still won't have mod permissions for them because of the uplevel directory permissions.

For instance, I noted iRecordMusic belongs to me (mkrishnan:mkrishnan) but I am not allowed to delete it without authenticating.
 
mkrishnan said:
I don't think so... applications you installed will still belong to you (if you look at their ownership properties in /applications), but I'm not sure it matters from a security standpoint, because you still won't have mod permissions for them because of the uplevel directory permissions.

For instance, I noted iRecordMusic belongs to me (mkrishnan:mkrishnan) but I am not allowed to delete it without authenticating.
Click to expand...

Hmmm. This might be trickier than we thought.

This could be a problem. I'll have to test it.

It might be that if you have applications that have the SUID bit, that you installed while you were an admin, then you changed to a regular user and did not change the owner and group, then MOAB could take them and own them too.

Even if you're a standard account.
 
Only when core system services are acting oddly after an install of a third-party app of unknown trustworthiness. Why? Because in general, Repairing Permissions is Useless.

One thing to remember, repairing permissions does not affect your home folder, at all. If you have permissions set incorrectly on a document in your home folder, you'll have to repair them manually; DIsk Utility's "Repair Permissions" button won't touch your home folder.
 
SC68Cal said:
There, you're done. You're no longer part of the admin group. You can verify by going to terminal and typing in id.

As long as all your values are > 500, then you're a standard user.

So for example, this is an admin account id output
Code: 
 admin$ id
uid=501(admin) gid=501(admin) groups=501(admin), 81(appserveradm), 79(appserverusr), 80(admin)

This is a standard user
Code: 
uid=502(user) gid=502(user) groups=502(user)
Click to expand...

Do you mean as long as it is greater than 501 and not 500.

Going from your example my account is still an admin account as

Code: 
rich$ id
uid=501(rich) gid=501(rich) groups=501(rich), 31(boinc_project), 30(boinc_master)

Also i have no idea what the boinc_project and bonic_master

SC68Cal said:
Hmmm. This might be trickier than we thought.

This could be a problem. I'll have to test it.

It might be that if you have applications that have the SUID bit, that you installed while you were an admin, then you changed to a regular user and did not change the owner and group, then MOAB could take them and own them too.

Even if you're a standard account.
Click to expand...

And yeah that is the sort of things i was trying to ask.
 
Do you mean as long as it is greater than 501 and not 500.
Click to expand...

Yes, thanks. Good eye. I think the best way to tell is not by the UID, but by the groups you belong to.

ehurtley said:
DIsk Utility's "Repair Permissions" button won't touch your home folder.
Click to expand...

Just adding to this. Disk Utility relies on the /Library/Receipts folder, and the .pkg files inside of that to determine what the correct permissions are.

If you can compromise /Library/Recipts, even that won't keep you safe.

You'll have to do what LMH says at the foot of MOAB 15

Also, verify that none of these files have been replaced (compare SHA-1 hash to a pristine installation) or tampered in some manner, as well as removing any rogue permissions:
Click to expand...
 
mad jew said:
After software updates and app installs. If I were more thorough, I'd do it before software updates and app installations too. Repairing permissions makes me hard in my pants.
Click to expand...


The same for me also - except for that last bit...

😱 😀
 
SC68Cal said:
Yes, thanks. Good eye. I think the best way to tell is not by the UID, but by the groups you belong to.
Click to expand...

How do i tell what group i'm in the way i see it from my previous post i'm in group 501 which is an admin group, right?

Therefore i'm confused, is my account still technically an admin one even though system preferences is telling me otherwise.
 
xUKHCx said:
How do i tell what group i'm in the way i see it from my previous post i'm in group 501 which is an admin group, right?
Click to expand...

No, not exactly... 501 is just a UID. If you were the first user you created on your Mac, even if you're not an admin, you'll usually always be 501. That doesn't really change.

You can use the groups command, I believe. A standard user will look like this:

Code: 
mkrishnan$ groups
mkrishnan

An administrator will look like this:

Code: 
administrator$ groups
administrator admin

Note how the administrator is part of a second listed group, "admin." That's the key.
 
xUKHCx said:
How do i tell what group i'm in the way i see it from my previous post i'm in group 501 which is an admin group, right?
Click to expand...

501 is just the first UID that gets assigned. Since Apple normally hooks that up with Admin privileges this is one indicator that you're an admin.

But again, the best is to check if you're part of the GID 80, 79 and 81.

I'm going to look into the package receipts issue, but perhaps even taking your first account on the computer, and deescalating it to a User account won't be enough.

Packages inside the /Library/Receipts folder are owned by the user that installed them, and have world-writable permissions. This isn't good, if what I'm thinking can actually work.

EDIT: I believe that id is a more precise tool than groups, I believe groups might be deprecated in fact. groups doesn't report on the appserver and appserver user groups, as well as that 31(boinc_project), 30(boinc_master) that xUKHCx had.
 
mkrishnan said:
No, not exactly... 501 is just a UID. If you were the first user you created on your Mac, even if you're not an admin, you'll usually always be 501. That doesn't really change.

You can use the groups command, I believe. A standard user will look like this:

Code: 
mkrishnan$ groups
mkrishnan

An administrator will look like this:

Code: 
administrator$ groups
administrator admin

Note how the administrator is part of a second listed group, "admin." That's the key.
Click to expand...

Ok cool, mine has some funky stuff after it but it seems as if that has something to do with a program I installed.

Code: 
Computer:~ rich$ groups
rich boinc_project boinc_master
 
Mitthrawnuruodo said:
But, SuperDuper! always repairs permissions as part of the backup procedure, and even if I've been slacking a bit lately, I still intend to run SD! at least once a week to have current backup, thus also keeping my permissions repaired... 😉
Click to expand...

That's the only time that I do it too - when SuperDuper! does it automatically.
 
There's no option for "When threads like this remind me to" 😛

So in theory less than "Monthly" but more regular than "Very Rarely".
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back