Systemwide Properties file on Lion


#1

I’d like to share my knowledge on this topic, since I’ve spent quite a long to time to find out how to do it.

The PropertiesFile class uses a file somewhere in /Library/Application Support or /Library/Preferences, which is protected against writing on Lion (and I think also Mountain Lion). This means a normal Application can only read the PropertiesFile but not write it. To be able to write to this folder, the Application has to be startet with root privilege.

It can be discussed, if it is good practice or not to write to /Library/Application Support but sometimes it can be necessary. A common way pointed out by an apple document is to split the part of the Application that does the root stuff into a seperate application and start it from the main Application. The binary file (Bundle/COntents/MacOS/…) must have to SUID Bit set, to ask for the root Password at startup.

This could be the solution, but the real ful began here: I already had a PropertiesFile in the target location and my application was not able to overwrite it with a new version, although the application was startet with root permission.

In the end I found, that the JUCE XML Class refuseses to write the file, because it checks the write permission by using File::hasWriteAccess(). This method itself uses the access() function to determine if it is allowed to write. Unfortunately access() only takes the real user ID into account and does not see that the user has root privilege due to the SUID BIt or a sudo command.

Now the question is: Is this a bug, or is this a feature. As far as I can see, a system wide PropertiesFile can not be written on Mac at all, unless root itself is logged in. (Is that possible on Mac? Anyway it is not desired.)

In my opinion the solution would be to change the File::hasWriteAccess() method in a way that is does not uses access() any more. Any other suggestions?


#2

TBH, I’d forgotten all about that stuff, but now that you’ve reminded me, it’s making me think that I should probably remove explicit support for system-wide properties altogether. Of course if someone really needs to do it, they can always just supply any filename they want for the PropertiesFile, but I think that it’s probably not something that should be encouraged!

What you say about access() is a bit odd - it seems strange that a posix function like that would return a result that’s incompatible with the way the other file functions behave… Is there any alternative to it?


#3

I get that information from here: http://linux.die.net/man/2/access

It sais "The check is done using the calling process’s real UID and GID, rather than the effective IDs as is done when actually attempting an operation (e.g., open(2)) on the file. This allows set-user-ID programs to easily determine the invoking user’s authority. "

I’ve read about an alternative, that simply tries to open the file with write permission (fopen(filename,“w”). If this succeeds, the right is granted.


#4

Interesting, thanks. I’ll have a think about that.