RefDB was written with facilitating the cooperation of users in mind. Therefore extended notes are visible to all users of the system by default. However, situations may arise where you don't want to share any notes or where you want to protect only individual notes from your colleague's prying eyes. RefDB supports all these variants. Accessibility of notes is controlled by two filters: the default server setting and the settings in the individual notes.
The refdbd server can be configured to either treat all extended notes as public or as private by default. Use the -S command line option or the share_default config file option to set the default mode. See the chapter about refdbd administration for further details. As the names imply, public will make all notes available to every user by default. Similarly, private will restrict access to the user who added the note by default. Use the server setting to define a default policy for your installation.
A warning for all admins: switching your server from "private" to "public" without prior announcement will alienate your users. Don't even think about it.
The xnote.dtd defines an optional share attribute which offers the same choice of values as the server setting above. If the attribute is set, the extended note will be public or private regardless of the server setting. The server setting only kicks in if a note does not set the share attribute. Each user can decide for each note whether or not she wants to share it with the world. The following table summarizes the settings.
Table 9.1. Sharing extended notes
| share attribute "public" | share attribute "private" | share attribute not set | |
|---|---|---|---|
| share_default "public" | public | private | public |
| share_default "private" | public | private | private |
The above settings control only the access to the extended notes through the RefDB interface. You should be aware that anyone who can access the database directly with an SQL client will be able to read and change the notes of every user, regardless of the settings mentioned above. The simplest way to secure the data is to run refdbd on a server that no user has shell access to. If the database engine access control is set in a way that users can only connect from the box that runs RefDB, they won't be able to connect from a SQL client running on their workstations.