| |
| Standards, Environments, and Macros | fns_files(5) |
| | fns_files - overview of FNS over files implementation |
| |
The Federated Naming Service (FNS) provides a method for federating multiple naming services under a single, simple interface for the basic naming operations. One of the naming services supported
by FNS is /etc files. FNS provides the XFN interface for performing naming and attribute
operations on FNS enterprise objects (organization, site, user, host, and service objects), using files as the naming service. FNS stores
bindings for these objects in files and uses them in conjunction with existing /etc files objects.
FNS Policies and /etc Files
| |
FNS defines policies for naming objects in the federated namespace (see fns_policies(5)). At the enterprise level, FNS policies specify naming for organizations, hosts, users, sites, and services. The enterprise-level naming
service provides contexts to allow other objects to be named relative to these objects.
The organizational unit namespace provides a hierarchical namespace for naming subunits of an enterprise. In /etc files, there is no concept of an organization. Hence, with respect
to /etc files as the naming service, there is a single organizational unit context that represents the entire system. Users in an FNS organizational unit
correspond to the users in the /etc/passwd file. FNS provides a context for each user in the /etc/passwd file.
Hosts in an FNS organizational unit correspond to the hosts in the /etc/hosts file. FNS provides a context for
each host in the /etc/hosts file.
|
Security Considerations
| |
Changes to the FNS information (using the commands fncreate(1M), fncreate_fs(1M), fnbind(1), fndestroy(1M) and fnunbind(1)) can be performed only by the privileged users on the system that exports the /var/fn directory. Also, based on the UNIX
user IDs, users are allowed to modify their own contexts, bindings, and attributes, from any machine that mounts the /var/fn directory.
For example, the command fncreate(1M) creates FNS related files and directories in the system on which the command is executed. Hence, the invoker of the fncreate(1M) command must have super-user privileges in order to create the user, host, site, and service contexts. However, a
user could use the fnunbind(1) command to create calendar bindings
in the user's own context, as in this example:
fnbind -r thisuser/service/calendar onc_calendar onc_cal_str jsmith@beatrix
The files object name that corresponds to an FNS composite name can be obtained using fnlookup(1) and fnlist(1).
|
|
| |
The files used for storing FNS information are placed in the directory /var/fn. The machine on which /var/fn is located has access
to the FNS file. The FNS information can be made accessible to other machines by exporting /var/fn. Client machines that NFS mount the /var/fn directory would then be able to access the FNS information.
|
| |
fnbind(1), fnlist(1), fnlookup(1), fnunbind(1), fncreate(1M), fncreate_fs(1M), fndestroy(1M), xfn(3XFN), fns(5), fns_initial_context(5), fns_nis(5), fns_nis+(5), fns_policies(5), fns_references(5)
|
| |
