Well, thank you Michael and Steve for your prompt replies ..... I still have one problem though .... the application I mentioned is primarily going to be used not from the command line. This application provides an API to be used by testers to write testcases, and use this API to start, as an example, a process as a different user. However, we would like to make sure they can start a process as another user by authenticating them (i.e., by making sure they know the password of the user they want to start the process as). So, for example, we have an API that takes a string that tells the app what to do on what machine, something like: unsigned int submit(char *machine, char *service, char *request) where request can be something like: "start process xclock asuser benjamin passwd mypwd" -- I have italized user options Now, we know that this is "dangerous" because the string is stored in the app in ASCII. using the passwd/crypt or shadow/crypt authentication model, we can crypt mypwd and pass the encrypted version (although we know this can be broken too). the problem with the current conversation model provided by pam is that the app would block waiting for input and would defeat the entire purpose of the app which is "automation". this app is not intended to be bullet proof. all we are trying is to provide some way of authenticating users (ideally using the platform's default protocol, like shadow/crypt on most unices except linux) just to ensure they can start a process as another user. in fact, we are also giving the option to configure the app so that it skips authentication if they so desire, but we want people to have a choice on this respect. since we plan on linux being our most widely used platform, and most linux boxes authenticate through PAM, we are pretty much stuck (at least until now). we would like to avoid telling people to change their authentication protocol. we want to make things as simple as possible for the user, but still allow some sort of security mechanism just to avoid accidental use as instead of malicious use. any ideas? Benjamin S. Vera-Tudela Software Engineer IBM e-boss - Austin, Texas Phone: (512)-838-8246 E-Mail: bveratudela@us.ibm.com Michael Gerdts <Michael.Gerdts@usa.alcatel.com>@redhat.com on 12/14/2000 10:04:24 AM Please respond to pam-list@redhat.com Sent by: pam-list-admin@redhat.com To: pam-list@redhat.com cc: Subject: Re: Passing password through a PAM-API On Thu, Dec 14, 2000 at 08:33:11AM -0600, Benjamin S Vera-tudela wrote: > $ myapp login [user] passwd [password] > Are you sure that you really want to do that? Anyone else on the box can then use ps(1) to get passwords of others. > Second, I noticed in the PAM website that an example application requires > application writers that wish to use PAM to add a couple of lines in the > /etc/pam.conf file that look like this: > > [service name] auth required [pam auth library name] > [service name] account required [pam acct library name] > > Is it possible to avoid having to do this? I believe that one option is to > provide your own authentication module (library) -- in the same way login, > su, and other Linux apps do --, and link your application to that module. > Are there any other options? Having to provide another library in my > application is the last option, so modifying the pam.conf file is probably > ok, but if there is an option that does not require providing a new library > and changing the pam.conf file, I would be glad to know about it. Most pam implementations pay use other (OTHER for HP-UX) as a catchall for apps that do not use any special library. If all of your apps only needed pam_unix, the following would be all that you really need other auth required /lib/security/pam_unix.so.1 other account required /lib/security/pam_unix.so.1 other session required /lib/security/pam_unix.so.1 other password required /lib/security/pam_unix.so.1 Mike _______________________________________________ Pam-list@redhat.com https://listman.redhat.com/mailman/listinfo/pam-list
