Re: PAM and the pwd.h interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 12, 2001 at 10:40:56AM -0700, Chris Jaeger wrote:
> Hi Phil,
> 
> 	The imap and ipop clients from the imap-2000 rpm;
> su from sh-utils (and I believe others too), various utilities
> in util-linux, proftpd... The format that everyone seems to be following
> is:
>  pw = getpwnam(name); 
>  if(pw) { 
>    pam_start("...", pw->pw_name, ...);
>    pam_authenticate(...);
>    ...
>  }

That's bad!

:)

> 	login from login-utils is one of the apps that
> seems to do it right.
> 
> 	Part of the problem in some of these utilities is
> that they attempt to decide if the operation is disallowed
> for reasons other than lack of authentication before trying
> to authenticate. For example, chsh will try to determine if
> an account is being managed locally or by NIS prior to
> authentication; if it is being managed by NIS, then it won't
> proceed and suggests ypchsh instead. It checks this by using 
> getpwnam. This particular example is an attribute-write, so
> this may fall into the case that Mark and Nicolas are debating
> over. 

I don't see how chsh can determine the name service whence getpwnam()
got a struct pwd's info.

In my environment chsh would not work, and it's not expected to work.
It's not a big deal, after all, shell changes are few and far between.

Also, we can produce a replacement chsh to work with our environment,
but noone is aking for it.

That said, a user's shell is an easy thing to change no matter what the
name service might be. Other user profile attributes are harder to
update, e.g., group memberships. The DB we use models each group
membership as a separate object that references the group and the
member. Now things get a bit complicated.

> 	I've tried to contact the various maintainers of
> these packages to determine if they would accept a patch
> that uses PAM to determine user-existence, but in general
> I've simply encountered silence. I'm also a little bit
> concerned because while PAM can be used to check for user
> existence (via pam_authenticate()), this may have more side-
> effects than desired (e.g. the need to actually authenticate,
> etc.). 

With some authentication services you must authenticate in order to
determine user existence. Think about ActiveDirectory, which can be
configured so some entities (e.g., authenticated hosts) can see less of
the directory than others (e.g., authenticated users).

It's just something you have to live with.

But, and here things get a bit more complicated still, user
authentication need not be password-validation. In the case of imap, pop
and other network services user authentication can be as in Kerberos,
NTLM, PKI, and so on.

In order to perform lookups against some naming services (e.g.,
ActiveDirectory), what you really need is valid user credentials (e.g.,
Kerberos TGTs). Thus, a way of passing such creds to PAM would appear to
be necessary in order to proceed with a user profile lookup API tied to
PAM.

A better approach might be to not tie the user profile lookup API to
PAM, but instead have a standalone API that can take credentials of
various types, including PAM handles.

> Regards,
> Chris
> 

Cheers,

Nico
--





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux