On Thu, Jun 10, 2010 at 8:26 PM, Phillip Moore <[email protected]> wrote: > Now that we have Kerberos authentication, I don't want to rip out the PAM > support, since non-Kerberos enabled sites should be to use EFS. > But, given the ugliness and complexity of the password caching code, and the > fact that every last security expert won't like it (and we don't have much > grounds to argue with them), why not just trash it? > IOW, you'll still be able to authenticate password in efsd via PAM, but the > client will require you to submit the password every time, instead of > caching it (or attempting to) in ~/.efsconfig. > Thoughts? > that means efs without kerberos basically won't allow batch jobs, unless each job somehow manages a password cache outside of efs. if we go down this route, we must make it extremely clear to efs admins and users that if selecting pam auth over kerberos, it will negatively impact the ability to run batch jobs within efs in environments where, for example, service account passwords are not shared with developers who run scripts using these accounts.
let's drop password caching. it's unlikely to impact anybody today and in the near future. as our support for and reliance on kerberos grows, we'll have an even better understanding of the security risks and mitigation strategies that may allow us to develop or help a contributor develop an alternative solution to kerberos. in the meantime, we'll have less ugly code to stare at, fewer security risks, and fewer bugs due to unused code (which is generally under-tested). ~jerry _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
