NAME
fns_files − overview of FNS over files implementation
DESCRIPTION
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).
USAGE
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.
SEE ALSO
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)