Welcome to the MacNN Forums.

spalding12 · Oct 26, 2003, 08:21 AM

sorry to bother you with these inane, pedestrian questions... but i DID already repair my permissions on my rev.b powerbook 17" BEFORE i have installed panther (the new disc is right next to me)

but i would like to know what this means exactly.......

and while we are at it.....
what are HAXIES......
is that like the CACHE of my windoze days?

ok
sorry to bother you
i'm probably the only one who doesn't know this stuff who's up this early on this forum

greg

Detrius · Oct 26, 2003, 09:14 AM

Repairing permissions reads the "receipts," which are files left over as evidence that you installed a certain piece of software, and it goes through your file system and makes sure that user and group priveleges on files are what they should be. For example: you DON'T what standard users to be able to modify your /etc/rc scripts, as that would enable them to give themselves root access next time you boot the system. You also don't want normal users to be able to modify anything in the /System/Library directory. Also, if permissions on some files are wrong, your system just flat out will not boot.

Haxies are hacks to the user interface.

spalding12 · Oct 26, 2003, 10:22 AM

thank you for that education
i appreciate it

greg

SalBaker · Oct 26, 2003, 07:04 PM

Can you run the Repair Permissions utility from your HD, or do you have to do it from the boot CD?

d4nth3m4n · Oct 26, 2003, 07:30 PM

Originally posted by SalBaker:
Can you run the Repair Permissions utility from your HD, or do you have to do it from the boot CD?

try it off the hard drive then get back to us.

Boondoggle · Oct 26, 2003, 08:17 PM

Can you run the Repair Permissions utility from your HD, or do you have to do it from the boot CD?

smartass replies aside, you can repair permissions when logged in an administrative account using the Disk Utility app. in the Utilities folder without using the boot CD

bd

SalBaker · Oct 27, 2003, 05:41 PM

Originally posted by d4nth3m4n:
try it off the hard drive then get back to us.

Okay, I did. It worked fine. Hope this helps.

iDaver · Oct 27, 2003, 05:49 PM

While on this subject; when backing up my applications in preparation for an erase and install, I got a message that some things could not be copied because I didn't have proper permissions. Well, I checked the file sizes of both the original folder and the backup folder and it would appear that all my apps were indeed copied.

What's with that, and how would I get around it? It doesn't seem like one would need to log in as root, just to copy all applications.

(I repaired permissions before doing the copy, but still got that message, and I'm the only user on my machine; no other accounts.)

iohead · Oct 27, 2003, 06:06 PM

Originally posted by iDaver:
While on this subject; when backing up my applications in preparation for an erase and install, I got a message that some things could not be copied because I didn't have proper permissions. Well, I checked the file sizes of both the original folder and the backup folder and it would appear that all my apps were indeed copied.

What's with that, and how would I get around it? It doesn't seem like one would need to log in as root, just to copy all applications.

(I repaired permissions before doing the copy, but still got that message, and I'm the only user on my machine; no other accounts.)

Some applications are "setuid" (to root, or some other user). This means when you run the application, it runs as the owner, and not as you. When you copy such a file, you need to be a privileged user, or the owner, in order to copy it with the setuid bit maintained. The file would still get copied though, that's why you are seeing no difference in file size.

Note that an application can also be "setgid" (group, instead of user).

-A

iDaver · Oct 27, 2003, 06:26 PM

Originally posted by iohead:
Some applications are "setuid" (to root, or some other user). This means when you run the application, it runs as the owner, and not as you. When you copy such a file, you need to be a privileged user, or the owner, in order to copy it with the setuid bit maintained. The file would still get copied though, that's why you are seeing no difference in file size.

Note that an application can also be "setgid" (group, instead of user).

-A

Thanks. I take it this means the app will still run after being backed up and restored. I wonder how this happens and whether it's a problem. It's not like I'm using pirated software even though, from your explanation, it sounds like it.

fmalloy · Oct 27, 2003, 07:16 PM

The question becomes - why do you need to repair file permissions at all? How do they get broken?

iohead · Oct 27, 2003, 07:40 PM

Originally posted by iDaver:
Thanks. I take it this means the app will still run after being backed up and restored. I wonder how this happens and whether it's a problem. It's not like I'm using pirated software even though, from your explanation, it sounds like it.

No - the application that needed setuid/setgid will not always run properly if this gets broken.

I don't have a Mac right this moment, but an example of a command line utility that is typically setuid would be "ping". The way ping works requires privileged access (it uses certain kind of network sockets that need root access). For any "normal" (non-root) user to execute ping, it has to be setuid root. This is the traditional Unix way of allowing access to a privileged set of operations on a per-program basis (in this case, the special network sockets would be usable by a normal user only while running ping, not elsewhere - because that would be a security threat).

Thus, for your programs to work correctly (or work at all), their setuid/setgid bits need to be preserved.

Which application were you trying to copy when this happened? Virtual PC has (at least one) setuid/setgid component, for example.

-A

iohead · Oct 27, 2003, 07:46 PM

Originally posted by fmalloy:
The question becomes - why do you need to repair file permissions at all? How do they get broken?

Permissions should *not* get broken on a sane system.

I'm not saying that Mac OS X is insane, but permissions are a relatively new addition. Whenever you install something (non-Apple third party applications particularly), and whenever you are prompted for an administrator password, the installer can do whatever it wants on the filesystem. It can modify existing files and their permissions on the system. If the application was not written with permissions in mind, or has not been carefully updated to respect permissions, the installer may mess up things while it is executing as root, etc.

I would say the concept of permissions is still transitional on Mac OS X, as is indicated by "repair permissions". It is rather ridiculous, actually!

-A

iDaver · Oct 27, 2003, 07:55 PM

Originally posted by iohead:

Which application were you trying to copy when this happened? Virtual PC has (at least one) setuid/setgid component, for example.

Well, that's the frustrating part. I was simply copying my entire applications folder. The message was "some files cannot be copied" but there were no specifics. Thanks for the detailed response.

iohead · Oct 27, 2003, 08:38 PM

Originally posted by iDaver:
Well, that's the frustrating part. I was simply copying my entire applications folder. The message was "some files cannot be copied" but there were no specifics. Thanks for the detailed response.

From a terminal window, type the following command at the shell prompt:

find /Applications -perm -4000

or

find /Applications -perm -u+s

This should give you a list of files under /Applications that have their setuid bit set.

-A