10.6.1 & Repair Permissions

In article <copespaz->,
MC <> wrote:

> Repair Permissions found quite a lot to fix when I applied the 10.6.1
> upgrade - suggest you don't omit this step.

Could we try not to propagate this one for the rest of history?

http://daringfireball.net/2006/04/re...issions_voodoo

--
"The game of professional investment is intolerably boring and over-exacting to
anyone who is entirely exempt from the gambling instinct; whilst he who has it
must pay to this propensity the appropriate toll." -- John Maynard Keynes

ZnU <> wrote:

> In article <copespaz->,
> MC <> wrote:
>
> > Repair Permissions found quite a lot to fix when I applied the 10.6.1
> > upgrade - suggest you don't omit this step.
>
> Could we try not to propagate this one for the rest of history?
>
> http://daringfireball.net/2006/04/re...issions_voodoo

Indeed. I don't recall the last time I did a repair permissions on any
of my Macs; it has probably been multiple years, and I don't forsee
doing one anytime in the near future. I certainly didn't do one when I
installed 10.6.1 (or 10.6). No obvious problems as a result of that (or
anything else really). As noted in the linked article, changes made by
repair permissions aren't necessarily really "repairs" anyway. If repair
permissions actually is routinely necessary, then something is seriously
*BROKEN* and it isn't just permissions. That would raise the question of
why the permissions got wrong. They simply should not go wrong in a
stable system.

I'd suggest that those who regularly find their system permissions
actually broken (not just different from what repair permissions
suggests) must have some malware on their system and perhaps should
install some virus protection, but that would start another one of those
similarly bogus threads. :-)

If one actually find that permissions are broken, then one ought to find
out what is breaking them and fix the problem instead of just patching
the symptoms.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Richard Maine wrote:
> anything else really). As noted in the linked article, changes made by
> repair permissions aren't necessarily really "repairs" anyway. If repair
> permissions actually is routinely necessary, then something is seriously
> *BROKEN* and it isn't just permissions. That would raise the question of

In fact, because I do (VERY SELDOM but not never) have to repair
permissions, I have a script to undo the "damage" that repair
permissions does. I DO NOT AGREE with Apple that everything
in /Applications/Utilities and /Developer should be usable
by everyone.

Repair permissions, IMHO, should ONLY work on system directories,
and the only time anyone (including me) needs to do that is if
they were "tinkering" and screwed up.

--
Wes Groleau

achy breaky grammar
http://Ideas.Lang-Learn.us/WWW?itemid=229

In article <1j5xy35.5c02zr1atitqN%>,
ure (Richard Maine) wrote:

> ZnU <> wrote:
>
> > In article <copespaz->,
> > MC <> wrote:
> >
> > > Repair Permissions found quite a lot to fix when I applied the 10.6.1
> > > upgrade - suggest you don't omit this step.
> >
> > Could we try not to propagate this one for the rest of history?
> >
> > http://daringfireball.net/2006/04/re...issions_voodoo
>
> Indeed. I don't recall the last time I did a repair permissions on any
> of my Macs; it has probably been multiple years, and I don't forsee
> doing one anytime in the near future. I certainly didn't do one when I
> installed 10.6.1 (or 10.6). No obvious problems as a result of that (or
> anything else really). As noted in the linked article, changes made by
> repair permissions aren't necessarily really "repairs" anyway. If repair
> permissions actually is routinely necessary, then something is seriously
> *BROKEN* and it isn't just permissions. That would raise the question of
> why the permissions got wrong. They simply should not go wrong in a
> stable system.
>
> I'd suggest that those who regularly find their system permissions
> actually broken (not just different from what repair permissions
> suggests) must have some malware on their system and perhaps should
> install some virus protection, but that would start another one of those
> similarly bogus threads. :-)
>
> If one actually find that permissions are broken, then one ought to find
> out what is breaking them and fix the problem instead of just patching
> the symptoms.

Some people feel the need to perform various periodic incantations to
ward off evil or something.

There are some things the system is supposed to do periodically. It does
them without being told. There are no regular maintenance tasks that
users of OS X need to manually perform. None. Really. Let the system
take care of itself. Keep backups in case something goes really wrong.
That's it.

--
"The game of professional investment is intolerably boring and over-exacting to
anyone who is entirely exempt from the gambling instinct; whilst he who has it
must pay to this propensity the appropriate toll." -- John Maynard Keynes

In article <>,
Elden Fenison <> wrote:

> * Richard Maine [09/13/09 00:44 UTC]:
> > If one actually find that permissions are broken, then one ought to
> > find out what is breaking them and fix the problem instead of just
> > patching the symptoms.
>
> I remember when I got my first mac and saw the repair permissions
> thing. I was used to FreeBSD. I was thinking what kind of rinky dink
> OS is this that needs a repair permissions utility?

There is no technical reason why this is more necessary on OS X than on
other *nix systems. Apple merely provides a way to restore the
permissions of system components to their defaults as a convenience.

> It's always interesting when you install an Apple product and then
> immediately run the repair permissions thing. It used to be fairly
> routine that it'd find the permissions on the software you just
> installed to be wrong.

Except they're *not* wrong. I don't understand why this needs to be
repeated so many times.

> Pretty darn sloppy if you ask me.

I expect it would be quite common, if other operating systems had a
similar feature, to find that after booting a system for the first time
some permissions had changed from those set by the installer. Processes
running on the system are not necessarily in flawless agreement with
installer package data about what permissions certain files should have.
This does not mean that either the installer or the relevant processes
are wrong, because there are multiple valid sets of permissions for most
files.

--
"The game of professional investment is intolerably boring and over-exacting to
anyone who is entirely exempt from the gambling instinct; whilst he who has it
must pay to this propensity the appropriate toll." -- John Maynard Keynes

On 2009-09-13, Elden Fenison <> wrote:

> I remember when I got my first mac and saw the repair permissions
> thing. I was used to FreeBSD.

Did you never run a script like unix-privesc-check to check permissions
on FreeBSD installs? I used to run a similar script on Solaris servers:

"Unix-privesc-checker is a script that runs on Unix systems (tested on
Solaris 9, HPUX 11, Various Linuxes, FreeBSD 6.2). It tries to find
misconfigurations that could allow local unprivilged users to escalate
privileges to other users or to access local apps (e.g. databases)."

http://pentestmonkey.net/tools/unix-privesc-check/

The thing to understand about "check permissions" under Mac OS X is that
the permissions on the files it flags up are not necessarily wrong and
that "repair permissions" is an unfortunate misnomer.

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/

Ian Gregory wrote:
> On 2009-09-13, Elden Fenison <> wrote:
>> I remember when I got my first mac and saw the repair permissions
>> thing. I was used to FreeBSD.
>
> Did you never run a script like unix-privesc-check to check permissions
> on FreeBSD installs? I used to run a similar script on Solaris servers:

There is little similarity between a tool that looks for conditions
known to be exploitable, and a tool that compares almost all file
permissions against some not-universally-accepted "standard" list.

--
Wes Groleau

Do people learn languages by studying grammar? Of course.
http://Ideas.Lang-Learn.us/barrett?itemid=996

On 2009-09-13, Wes Groleau <groleau+> wrote:
> Ian Gregory wrote:
>>
>> Did you never run a script like unix-privesc-check to check permissions
>> on FreeBSD installs? I used to run a similar script on Solaris servers:
>
> There is little similarity between a tool that looks for conditions
> known to be exploitable, and a tool that compares almost all file
> permissions against some not-universally-accepted "standard" list.

If an installer sets or modifies permissions on a file during
installation of a package then it should record those permissions in a
BOM file. There is no question of whether or not those permissions are
"universally-accepted" or not; they were the permissions set by the
installer and if they are now different then something must have changed
them. That *may* have been another (perhaps poorly designed) installer
which has consequently introduced a privilege escalation vulnerability,
or it *may* have been a conscientious sysadmin hardening the system.

As a Unix sysadmin how you manage (check and modify) permissions is
entirely up to you. Apple have provided some functionality in Disk
Utility which can be helpful but there is no need to use it if you don't
want. You might prefer to check permissions using a bunch of find(1)
commands or by downloading and running some scripts, or perhaps do
nothing and remain blissfully unaware of any problems. Same as you might
do with FreeBSD.

The only problem with "repair permissions" is that it is so widely
misunderstood.

Ian

--
Ian Gregory
http://www.zenatode.org.uk/ian/

Ian Gregory wrote:
> On 2009-09-13, Wes Groleau <groleau+> wrote:
>> Ian Gregory wrote:
>>> Did you never run a script like unix-privesc-check to check permissions
>>> on FreeBSD installs? I used to run a similar script on Solaris servers:
>> There is little similarity between a tool that looks for conditions
>> known to be exploitable, and a tool that compares almost all file
>> permissions against some not-universally-accepted "standard" list.
> The only problem with "repair permissions" is that it is so widely
> misunderstood.

It's certainly misunderstood if you think it is similar
to unix-privesc-check

--
Wes Groleau

I’ve Been Scribd!
http://Ideas.Lang-Learn.us/russell?itemid=1470

In article <>,
Elden Fenison <> wrote:

> * ZnU [09/13/09 20:01 UTC]:
> >> It's always interesting when you install an Apple product and then
> >> immediately run the repair permissions thing. It used to be fairly routine
> >> that it'd find the permissions on the software you just installed to be
> >> wrong.
> >
> > Except they're *not* wrong. I don't understand why this needs to be repeated
> > so many times.
>
> Well first of all... this is the first post I've read from you. So you may
> have been repeating it... but I was never involved.

The post you were replying to was a post agreeing with my post about how
repairing permissions as routine maintenance was nonsense.

> I misspoke. Let me rephrase. The permissions on the installed software
> components (immediately after install) did not agree with what the permissions
> repair utility said they should be. Maybe that doesn't mean they are "wrong".
> But I'd prefer the permission "repair" utility and the installer agree on what
> the permissions should be. That seems like a no-brainer.

Honestly, why? If the installer sets one set of permissions that work
fine, and some system process that works with a file you'll never
directly interact with sets some other set of permissions that work just
fine, why would you, and an end user, ever have the slightest reason to
care?

--
"The game of professional investment is intolerably boring and over-exacting to
anyone who is entirely exempt from the gambling instinct; whilst he who has it
must pay to this propensity the appropriate toll." -- John Maynard Keynes