On Wednesday, 09 April 2003, at 16:49:43 (+0200),
Cristalle Azundris Sabon wrote:
> Normally, getpwnam() will heed nsswitch.conf (if the system even has
> one, not peering BSD-wards here):
>
> These functions are used to obtain password entries. Entries can
> come from any of the sources for passwd specified in the
> /etc/nsswitch.conf file (see nsswitch.conf(4) ).
>
> Basically, you can get user-data from anything that's mentioned in
> your nsswitch.conf (and that you actually do have a configured plugin
> for, nss_ldap.so and friends). Your program may be backend agnostic;
> the data will look the same no matter whether they came from LDAP, NIS,
> or the desert. (I.e., if for some arcane reason the LDAP model does not
> use the posixAccount object-class, it is the responsibility of the
> plugin to query the right attributes and return them in proper format etc.)
>
> As long as it's only the home-dir you're interested in, getpw...() should
> be fine.
>
>
>
> However, if PAM exists, and you want to check auth-credentials (to log
> somebody in), you must go through PAM:
>
> LDAP allows ACLs with a rather high granularity. Hence, on a system that
> has both PAM and NSS, we are likely to find the following setup:
>
> - A DN ("user") in LDAP nss_ldap may log into the LDAP as. This
> "user" may read all the data normally stored in /etc/password, but
> not the data from /etc/shadow, specifically not the password. It
> doesn't need to know the password -- that's only used for auth,
> which is done in PAM, so NSS doesn't need access to the pwd. This
> way, all NSS-related stuff (uid->user-name mapping for ls, top, ps
> and friends) will work as always, but password hashes cannot be
> listed ("ypcat passwd" issue in NIS).
>
> - A DN in LDAP pam_ldap may may use to auth against the LDAP server.
> This "user" will see the password-data (hashed or otherwise), but
> to know the semi-secret DN and its secret password, one would have
> to read pam_ldap.conf, which is owned by and read-only to root.
> PAM-stuff usually runs as root ; ), so it gets the data it needs.
> NSS-stuff gets only the data it needs, which excludes password data.
>
> The general upshot is that password data are only readable to root,
> unlike in many YP/NIS setups.
>
> The specific upshot is that when PAM exists on a system, a setup as
> described above is possible, perchance likely. Hence, if the entrance
> is to work on systems with and without PAM (with passwords in files,
> LDAP, NIS, or wherever), the following applies.
>
> - If there is no PAM, we can with reasonable safety assume that there
> also isn't the setup described above. ; ) => use getpwnam() and friends.
>
> - If PAM exists, NSS may or may not be configured to get data from LDAP.
> Even if it is, there is no guarantee that these data will include
> password data. => go through PAM
>
> I'm in a bit of a hurry, so I didn't have a chance to edit this off the
> top of my head rant much. Hope it helps either way.
heh I'm just not nearly verbose enough, am I? :-)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"Sometimes I give myself the creeps. Sometimes my mind plays tricks
on me. It all keeps adding up; I think I'm cracking up. Am I just
paranoid? Am I just stoned?" -- Green Day, "Basket Case"
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
