The conversation function is provided by your app. If the app knows the answer to a prompt then it need not engage in any I/O... On the other hand, if the app knows the user's password before getting to PAM (apps like XDM would, as they prompt for username and password in one go), then you have a bit of a problem as LinuxPAM does not allow the app to do a pam_set_item() on the PAM_AUTHTOK item. This is very unfortunate. I brought this up recently here and had no response, probably because I didn't include a patch to implement what I was proposing; perhaps I will, thnough not soon. Nico On Thu, Dec 14, 2000 at 10:38:54AM -0600, Benjamin S Vera-tudela wrote: > 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 > > > > > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list --
