The upgrade to 5.2 creates /etc/pam.d/system-auth.rpmnew. I see that /etc/pam.d/system-auth actually is a symlink to system-auth-ac. Is it recommended to replace that symlink with the rpmnew file?
Kai
On Sun, 2008-06-29 at 14:57 +0200, Kai Schaetzl wrote:
The upgrade to 5.2 creates /etc/pam.d/system-auth.rpmnew. I see that /etc/pam.d/system-auth actually is a symlink to system-auth-ac. Is it recommended to replace that symlink with the rpmnew file?
IMO, it's never OK w/o first examining the effects. The rpmnew is provided specifically because replacing the previous one may be highly destructive to the aims of that system's users/admins.
I've not looked, but I suspect the rpmnew needs to be compared to the target of the symlink. I just finished watching some threads where some add on packages provided symlinks inside other package directories in order to provide the support needed with minimal disruption to the original package.
Kai
HTH
William L. Maltby wrote on Sun, 29 Jun 2008 09:09:17 -0400:
IMO, it's never OK w/o first examining the effects. The rpmnew is provided specifically because replacing the previous one may be highly destructive to the aims of that system's users/admins.
I've not looked, but I suspect the rpmnew needs to be compared to the target of the symlink.
That's the point and why I'm asking. I think the rpmnew got created because the target is a symlink (I think normally rpm overwrites a config file if it has not been changed from the previous version, this obviously is bound to fail in this case). The question now is, should it have actually replaced system-auth-ca, was the symlink incorrect in the first place, should there be both system-auth and system-auth-ca be available in parallel, or what? I don't know for what exactly both or just one of the files gets used, I can just assume it's some authorization. And ca file might get used when authorizing with a certificate (remote or with a card?). I don't find myself in a position to assess the difference between the files and what it means for security. The main difference between the files seems to be something about user-ids above/below 500.
Kai
On Mon, 2008-06-30 at 13:14 +0200, Kai Schaetzl wrote:
William L. Maltby wrote on Sun, 29 Jun 2008 09:09:17 -0400:
IMO, it's never OK w/o first examining the effects. The rpmnew is provided specifically because replacing the previous one may be highly destructive to the aims of that system's users/admins.
I've not looked, but I suspect the rpmnew needs to be compared to the target of the symlink.
That's the point and why I'm asking. I think the rpmnew got created because the target is a symlink (I think normally rpm overwrites a config file if it has not been changed from the previous version, this obviously is bound to fail in this case). The question now is, should it have
I'm not sure if it being a symlink is a determinant. Nor am I sure about "if modified". I do recall rpmnew files being created when no symlink was involved (caveat: wetware memory is highly unreliable).
In cases where an rpmnew was not created, there is often an rpmsave. This is a copy of the file that was replaced. IIRC, it does not matter if the original was previously modified or not.
My SOP is: after updates, run updatedb, do locate for rpmnew and rpmsave, examine for differences between found and originals/related files, adjust as needed.
As a former developer, I would suspect that I would *not* try to determine creation of files based on a test for modification of the original. It would increase the complexity and unreliability of the update process (would it approach the unreliability of depending on the user/admin to properly examine and adjust? Probably not.) and go counter to the innate laziness of us all. Combine the two factors and a strong argument is made against trying to detect changed base files.
Ditto for symlinks.
Having said all that, the scripted yum/rpm update processes may incorporate that detection process. I don't know.
actually replaced system-auth-ca, was the symlink incorrect in the first place, should there be both system-auth and system-auth-ca be available in
Using the yum or rpm facilities that tells what package provides the file or symlink should help. I think it's --provides or whatprovides or somesuch. Man pages will tell you.
parallel, or what? I don't know for what exactly both or just one of the files gets used, I can just assume it's some authorization. And ca file might get used when authorizing with a certificate (remote or with a card?). I don't find myself in a position to assess the difference between the files and what it means for security. The main difference between the files seems to be something about user-ids above/below 500.
That becomes a case of hoping there are adequate man pages. Even if not, if you compare the old and new and determine what you state above, it's likely that the update is OK to apply. YMMV, of course.
Kai
Kai Schaetzl wrote:
William L. Maltby wrote on Sun, 29 Jun 2008 09:09:17 -0400:
IMO, it's never OK w/o first examining the effects. The rpmnew is provided specifically because replacing the previous one may be highly destructive to the aims of that system's users/admins.
I've not looked, but I suspect the rpmnew needs to be compared to the target of the symlink.
That's the point and why I'm asking. I think the rpmnew got created because the target is a symlink (I think normally rpm overwrites a config file if it has not been changed from the previous version, this obviously is bound to fail in this case). The question now is, should it have actually replaced system-auth-ca, was the symlink incorrect in the first place, should there be both system-auth and system-auth-ca be available in parallel, or what? I don't know for what exactly both or just one of the files gets used, I can just assume it's some authorization. And ca file might get used when authorizing with a certificate (remote or with a card?). I don't find myself in a position to assess the difference between the files and what it means for security. The main difference between the files seems to be something about user-ids above/below 500.
I don't see a system-auth-ca on my 4 Centos5 systems.
My 3 systems still at C5.1 show the same:
ls -als /etc/pam.d/system-auth*
4 lrwxrwxrwx 1 root root 14 May 10 2007 /etc/pam.d/system-auth -> system-auth-ac 8 -rw-r--r-- 1 root root 848 May 10 2007 /etc/pam.d/system-auth-ac 4 -rw-r--r-- 1 root root 683 Nov 10 2007 /etc/pam.d/system-auth.rpmnew
rpm -q --whatprovides /etc/pam.d/system-auth pam-0.99.6.2-3.26.el5
rpm -q --whatprovides /etc/pam.d/system-auth-ac authconfig-5.3.12-2.el5
My test box at C5.2:
ls -als /etc/pam.d/system-auth*
4 lrwxrwxrwx 1 root root 14 May 20 09:09 /etc/pam.d/system-auth -> system-auth-ac 8 -rw-r--r-- 1 root root 844 May 20 09:09 /etc/pam.d/system-auth-ac 4 -rw-r--r-- 1 root root 683 May 24 13:35 /etc/pam.d/system-auth.rpmnew
rpm -q --whatprovides /etc/pam.d/system-auth pam-0.99.6.2-3.27.el5
rpm -q --whatprovides /etc/pam.d/system-auth-ac authconfig-5.3.21-3.el5
On Mon, Jun 30, 2008 at 08:54:29AM -0400, Toby Bluhm wrote:
ls -als /etc/pam.d/system-auth*
4 lrwxrwxrwx 1 root root 14 May 10 2007 /etc/pam.d/system-auth -> system-auth-ac 8 -rw-r--r-- 1 root root 848 May 10 2007 /etc/pam.d/system-auth-ac
system-auth-ac is the results of running authconfig and so could change if you want md5 passwords or whatever. system-auth should point to the -ac version if you want authconfig to work.
Toby Bluhm wrote on Mon, 30 Jun 2008 08:54:29 -0400:
rpm -q --whatprovides /etc/pam.d/system-auth pam-0.99.6.2-3.27.el5
rpm -q --whatprovides /etc/pam.d/system-auth-ac authconfig-5.3.21-3.el5
So, possible conclusion: they want to make pam self-sufficient, thus replacing the symlink to a file that comes with authconfig with their own file.
Kai
-
Kai Schaetzl -
Stephen Harris -
Toby Bluhm -
William L. Maltby