3.2. Programming with Directory Services
As a programmer, you frequently need to deal with
directory information, whether you realize it or not. Your
application uses Directory Services each time it looks up a host
entry, authenticates a password, or uses a printer. The Open
Directory architecture unifies what used to be a random collection of
flat files in /etc. The good news is that the
flat files still work. The other good news is that there is a brave
new world just beyond those flat files. So, while all your old Unix
code should work with the Open Directory architecture, you should
look for new ways to accomplish old tasks, especially if you can
continue writing portable code.
To get at directory information, Unix applications typically go
through the C library using such functions as gethostent(
). Higher-level APIs, such as Pluggable Authentication
Modules (PAM) and Common Data Security Architecture (CDSA), also use
the C library. Figure 3-2 shows how this works. The
C library connects to lookupd, a thin shim that
is the doorway to the DirectoryService daemon.
The DirectoryService daemon consults the
available plug-ins until it finds the one that can answer the
directory query.
Figure 3-2. Accessing Directory Services
3.2.1. Working with Passwords
One possible route to user and
password
information is through the
getpw* family of functions. However,
those functions are not ideal for working with systems like Mac OS X
that support multiple directories (flat files, NetInfo, LDAP, etc.).
In particular, getpwnam( ) is not guaranteed to
return a crypted password if the system has been configured to use
another scheme, such as MD5 passwords. You should use the
PAM API
instead. PAM is included with, or available for, many flavors of
Unix, so you can use it to write portable code. For more information
on PAM, see the pam(8) manpage.
 |  |  | 3. Directory Services |  | 3.3. Configuring Directory Services |
Copyright © 2003 O'Reilly & Associates. All rights reserved.
|
|