> On Wed, Feb 21, 2007 at 04:26:27PM -0500, Jamie ffolliott wrote: > > I just updated in debian testing today, on a system using > pam-ldap for > > authentication, and now I've got new issues that broke > authentiation > > for this server. It seems debian has saved certain > configurations and > > overwritten one or both of these settings: > > 1) /etc/libnss-ldap.conf : rootbinddn > > I've confirmed that this does happen on an etch upgrade, however...
Ok I said that as one of two possibilities since I couldn't tell exactly what the upgrade had done, the other possibility that could break it is modifying the .secret file. An upgrade does however comment out the "uri" setting in libnss-ldap.conf, and re-enable the "host" setting, which breaks an ldaps:// connection to the ldap server. The settings offered by the debconf settings do not allow me to specify a "uri" setting, therefore there is no way to avoid breaking the (secure ldap) authentication during an upgrade or dist-upgrade. > > None of what you are doing is apparent on an apt-get > update/upgrade. > > There was no prompt whatsoever that you were about to break > access to my system. > > Even most packages I've used in the last 7-8 years on debian do not > > overwrite critical settings on an upgrade unless they warn me it's > > happening. > > This claim is untrue. The first few lines of > /etc/libnss-ldap.conf state that "the configuration of this > file will be done by debconf as long as the first line of > this file says '###DEBCONF###' You should use > dpkg-reconfigure libnss-ldap to configure this file" > Obviously you had already opened the file in order to edit > it, so you must have seen the note. Ok. However, this warning does *not* appear within /etc/libnss-ldap.secret, simply because this file cannot contain comments, which I believe is a file that's written by debconf. So that may remain a problem. I wouldn't consider it secure to store an unencrypted password in debconf, as it does, which allows write access to the ldap directory that is in charge of storing passwords including root's. Preferably the .secret file should always be left alone after installed the 1st time. > I won't claim that this is the best or only way this file > could be handled, but it certainly isn't broken, per se. > Therefore, I don't think there's anything that has to be > changed before we can release etch. I see what you mean, but please consider the above comments again. To rehash - the debconf "host" setting only allows an insecure ldap connection, whereas "uri" isn't available in this package and yet it's needed to allow a secure connection over the network. Debconf probably should not store a sensitive password that allows write access to the directory (it could simply leave the password alone in the .secret file, there's no need to rewrite it). Thanks for having a look. Jamie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
