Yeah, well the code *is* tested.... I spent an afternoon (or was it a late night?) fighting Expect to make it work.
None the less, I agree. This was a feature we felt forced to implement, in order to make batch processes possible in the first place, but strategically, I see it as only a liability. It's gone in the next core update I make.... On Fri, Jun 11, 2010 at 9:29 AM, jerry gay <[email protected]>wrote: > 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 >
_______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
