Brian Pinkerton <email@hidden> wrote:
>I'm writing a server that provides services for all users on a
>particular machine. Various applications write preferences on behalf
>of individual users; the server reads those preferences and exports the
>services. The most convenient way for an application to write
>preferences for a user is to use NSUserDefaults and write to a
>persistent domain.
If that's an accurate description, I still don't understand how a
preference can be turned into an exported service. In fact, I'm not at all
sure what you're doing other than emulating Mac OS X's defaults subsystem
using a root-ID'ed server. No matter, though, because I'd still suggest
the same thing:
build on Preferences.
You can set a PreferencesFactory with a system property and presto your
apps then get a Preferences node that does whatever you care to do. The
API docs for the Preferences class seems to describe exactly what you want:
- - - - -
A node in a hierarchical collection of preference data. This class
allows applications to store and retrieve user and system
preference and configuration data. This data is stored
persistently in an implementation-dependent backing store. ...
- - - - -
The pivotal phrase is "implementation-dependent backing store", which is
where your implementation comes in. You just write that imp to talk to
your server, or to use the default implementation for the platform in all
other cases, and all your apps still continue to call the Preferences API
exactly as before. The Chain of Responsibility pattern seems obvious.
Exactly what your server does to or with each user's preferences data is a
completely different question. Or was that the question you were asking?
That is, did you want to know how to get the server to hook into the Mac OS
X defaults subsystem, so its actions would result in each user's apps
seeing the change?
If that's your question, then you can use the 'defaults' command to
accomplish that. However, it's not clear to me that it's necessary.
Let's say your server ISN'T running as root, and DOESN'T use the defaults
subsystem. It just stores settings in a database it controls. If all the
apps are using a PreferencesFactory that talks to the server, then there's
no problem, because all the interested apps are talking to the unprivileged
server. If an app that isn't talking to the server wants to do so, then it
should simply use the appropriate PreferencesFactory, or talk directly to
the server using the appropriate protocol.
So if the server is managing its storage, and the apps (clients) are simply
telling the server what to store, then the server doesn't need to run as
root. There are no privileged interactions between any clients, or between
the server and any client. Inter-client interactions are mediated by the
server itself, who imposes any constraints it wants, but is otherwise
running as an unprivileged user-ID.
Anyone who wants to talk to the server can do so directly and obtain all
the information they need. You don't need an omnipotent server "sending
messages" to clients by storing new values into each one's defaults. Yes,
you CAN do that, but given the risks for even slight imperfections in
design or execution, including seriously mangling system-required defaults
or even opening a root-exploit, I'm not sure why you'd want to.
As a general rule, if a design needs a perfectly secured omnipotent server
talking to arbitrary unprivileged clients exchanging data, then put that
design into a lead-lined container and bury it in an abandoned salt mine.
The PreferencesFactory property-name is
"java.util.prefs.PreferencesFactory", and the default value on Mac OS X is
"java.util.prefs.MacOSXPreferencesFactory". Inspecting a
properties-dumper's output on Windows shows the value is
"java.util.prefs.WindowsPreferencesFactory". This suggests a heuristic for
PreferencesFactory class-naming involving the "os.name" property, should
one be needed.
Also, the source for several "MacOSXPref*.java" files is included in the
"src.jar" installed with Mac OS X Java Developer Tools. They may be useful
in creating your own Preferences and PreferencesFactory.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
