Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A bit more detail on 'Special Permissions' in Disk Utility System
This hint might be a bit obvious to an expert, but the information seems somewhat obscure. During Disk Utility Permission Repair, you sometimes see messages along the lines of "We are using special permissions for the file or directory [some file or folder]. New permissions are [some values]." These messages show up every time you make repairs. According to Apple Support document 107298, you can safely ignore them. They are, in fact, just status messages to inform you that the default permissions specified for these files have been overriden elsewhere. But ever wonder where some of these special permission overrides are defined?

Point your text editor at /System -> Library -> PrivateFrameworks -> DiskManagement.framework -> Resources -> HintFile.plist, and have a look. In the specificFileSettings dict node, there's a set of entries with a path and a corresponding permissions value. You'll notice that Apple has already set some existing special permissions -- namely, the files named in the Disk Utility messages that you keep seeing. Adding new entries to this dict will allow you to specify special permissions to override those listed in in the BOMs in /Library/Receipts, and Disk Utility seems to faithfully apply the newly defined permission and inform you of it with a new "We are using special permissions..." message during repairs.

The permission values themselves seem odd. With values like 16877 (for /Library/Widgets in 10.4.2), these aren't the octal-representation permission settings normally used with chmod, but seem to be decimal conversions of those octal values. You also can't seem to put in just any arbitrary path -- specifying special permissions for a newly created file foo.txt in my home directory did not work. It is possible that Disk Utility only applies these override permissions for files already listed in a receipt.
    •    
  • Currently 2.00 / 5
  You rated: 3 / 5 (6 votes cast)
 
[14,615 views]  

A bit more detail on 'Special Permissions' in Disk Utility | 7 comments | Create New Account
Click here to return to the 'A bit more detail on 'Special Permissions' in Disk Utility' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A bit more detail on 'Special Permissions' in Disk Utility
Authored by: Durandal on Sep 22, '05 10:58:39AM
It's no surprise that Apple store the decimal representation of chmod permissions. NSNumber doesn't support reading in any base but 10. The framework probably has an internal function to convert the decimal into hex.

---
Damien Sorresso

[ Reply to This | # ]

A bit more detail on 'Special Permissions' in Disk Utility
Authored by: exel on Sep 22, '05 02:02:50PM

There is no need to 'convert' it to hex. The decimal string is just parsed as an integer and that's what is used by the chmod() kernel call.



[ Reply to This | # ]
A bit more detail on 'Special Permissions' in Disk Utility
Authored by: jb72 on Sep 22, '05 11:28:11PM
Errrr. What about this...
   <key>./usr/lib/php/build/acinclude.m4</key>
        <dict>
            <key>perms</key>
            <string>33060</string>
        </dict>
Is that a sign that I've been violated? (Yes I'm paranoid.)

[ Reply to This | # ]
A bit more detail on 'Special Permissions' in Disk Utility
Authored by: exel on Sep 23, '05 10:56:02AM

That file belongs to php. It's perfectly harmless.



[ Reply to This | # ]
A bit more detail on 'Special Permissions' in Disk Utility
Authored by: lavadude on Sep 30, '05 08:30:28AM

Let's hope it doesn't mean you've been violated, since I have the same string! And I also have

<key>./Library/ColorSync/Profiles/Displays</key>
<dict>
<key>perms</key>
<string>16893</string>
</dict>


Anyway, I'm still curious about the permission values and what they represent.

The numbers are decimal represenations of the octal values, but they're too big to match the standard modes, which top out at 4777 octal.

Common Unix chmod setting 0644 would be 420 decimal.
Common Unix chmod setting 0755 would be 493 decimal.
Common Unix chmod setting 4755 would be 2541 decimal.
Not common Unix chmod setting 4777 would be 2559 decimal, and it would be the largest value represented, according to the chmod man page (see man chmod

But if you look at the numbers in the file
/System/Library/PrivateFrameworks/DiskManagement.framework/Resources/HintFile.plist,
you'll note the following about the numbers

16893 decimal is 40755 in octal.
33060 decimal is 100444 in octal.

So it looks to me like Apple extended the bits used to manage the file attributes all the way up to at least 18 bits.

But what do these extra bits mean? They're not covered in the chmod manual page. However, just because they're not documented doesn't mean they don't exist.

/usr/include/sys/stat.h may hold some clues. While I have no proof of this, I'm guessing the following from the stat.h file is the extended meaning

#define S_IFMT 0170000 /* type of file mask */
#define S_IFIFO 0010000 /* named pipe (fifo) */
#define S_IFCHR 0020000 /* character special */
#define S_IFDIR 0040000 /* directory */
#define S_IFBLK 0060000 /* block special */
#define S_IFREG 0100000 /* regular */
#define S_IFLNK 0120000 /* symbolic link */
#define S_IFSOCK 0140000 /* socket */
#define S_IFWHT 0160000 /* whiteout */
#define S_ISVTX 0001000 /* save swapped text even after use */


Which seems to match up with the values in the HintFile.plist

/Library/ColorSync/Profiles/Displays is indeed a directory.
/usr/lib/php/build/acinclude.m4 is a regular file.

I wonder why they chose to do it this way, but it seems to be how it works...



[ Reply to This | # ]
A bit more detail on 'Special Permissions' in Disk Utility
Authored by: jms1 on Oct 09, '05 02:29:46AM

The chmod(1) and chmod(2) man pages don't document these "file type" bits because the chmod() function cannot change them. The stat(2) man page DOES document these values- type "man 2 stat" for a better explanation.

Side note- the value you're looking at is the "st_mode" value, which is defined as 16 bits (rather than 18 bits.) The highest possible value is 0177777 (which is 0xFFFF in hex, or 65535 decimal.)



[ Reply to This | # ]
How to determine a value for the permissions
Authored by: cmt on Nov 02, '05 07:06:13AM

Create a folder e.g. /Test
Set the permissions on this folder as you would like them (either through the GUI or command line)
Run the command:
stat -f "%Dp" /Test

This will then return the correct value to put in the string tag as detailed in the original hint.



[ Reply to This | # ]