Bug 194246 - authconfig and pam components have /etc/pam.d/system-auth conflict
authconfig and pam components have /etc/pam.d/system-auth conflict
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Mike McLean
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-06 12:12 EDT by Michael Carney
Modified: 2008-12-29 14:44 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-28 07:00:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch to rpm (948 bytes, patch)
2006-06-15 06:28 EDT, Tomas Mraz
no flags Details | Diff
Improved patch (1.44 KB, patch)
2007-02-13 09:41 EST, Tomas Mraz
no flags Details | Diff

  None (edit)
Description Michael Carney 2006-06-06 12:12:48 EDT
Description of problem:
pam is providing /etc/pam.d/system-auth as a file. authconfig
generates /etc/pam.d/system-auth-ac, and replaces /etc/pam.d/system-auth
with a symbolic link to /etc/pam.d/system-auth-ac. authconfig is run as part 
of firstboot.

Anytime pam is updated, the pam-provided version of /etc/pam.d/system-auth
is created as /etc/pam.d/system-auth.rpmnew.

Clearly, ownership of /etc/pam.d/system-auth conflicts between authconfig and 
pam. 


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Tomas Mraz 2006-06-07 07:18:16 EDT
This conflict is hardly solvable as you don't have to install authconfig for
minimum installation (kickstart driven) and still expect pam (login, sshd) to
work. The authconfig shouldn't be a required package. But on the other hand
authconfig must be able to modify that file. Probably rpm shouldn't make rpmnew
files in case the original and updated package files are the same.
Comment 2 Jeff Johnson 2006-06-08 08:33:16 EDT
rpm makes .rpmnew problems at the request of the packager, not otherwise.

So this is a packaging problem.
Comment 3 Tomas Mraz 2006-06-08 09:03:01 EDT
Well, Jeff, the system-auth file must be marked as %config(noreplace) in the pam
package because it is a configuration file which we don't want to overwrite if
it was modified.

The only other way would be to mark the file as a ghost and create it manually
in %post. But this is even more ugly.

I'd say wontfix then as it is a purely cosmetic issue.
Comment 4 Michael Carney 2006-06-08 14:06:01 EDT
How on earth can you consider the contents of /etc/pam.d/system-auth a 
"cosmetic" issue?? What is a end user supposed to do to resolve the conflict? 
The system-auth-ac produced by authconfig during firstboot is now different 
than that provided by updates to pam. Which component is the primary owner of 
the /etc/pam.d/system-auth? pam or authconfig??

I'm reopening this bug and changing the component to pam. Perhaps doing so 
will result in a better evaluation, I hope.
Comment 5 Tomas Mraz 2006-06-08 14:25:54 EDT
But it was always the case that the system-auth-ac (system-auth directly in
previous Fedora Core releases) created/written by authconfig were conflicting
with the default in the pam package.

The only difference from the previous situation is that the system-auth was
written to directly and rpm doesn't create .rpmnew files when the contents of
the file in the old and new package is the same and the file on disk is a
regular file.

Now the file on disk is a symlink and rpm incorrectly creates .rpmnew file
although the file in old and new package doesn't differ.

On the pam side I can see only one possible workaround, document the situation
in a comment in the system-auth file.
Comment 6 Michael Carney 2006-06-08 17:45:24 EDT
OK, so in the past there was only /etc/pam.d/system-auth, which was 
merged/written by upgrades of pam or invocations of authconfig, both of which 
considered the current contents of the file during the update. Not perfect, 
but at least it was consistent. Now it's not. This was due to your fix for
165342, which  points out that authconfig wasn't preserving/considering 
changes made by users, and maybe not updates to pam's version of the file 
either.

Wouldn't it have been a better to fix 165342 by making authconfig 
understand/preserve the user's changes rather than produce a parallel, manual 
system of update (system-auth-local), which because of the symbolic link, 
would still produce a rpmnew file when pam is updated? If making authconfig 
smarter would make it too unwieldy, than what about making authconfig only 
smart enough to recognize when the user has made manual changes to it that it 
doesn't understand, and simply fail/exit, with a message or dialog saying the 
file needs to be managed manually? Just a thought.

Meanwhile, should I just accept the system-auth provided in the latest pam 
update (system-auth.rpmnew -> system-auth-ac), keep the one authconfig 
created, or move system-auth.rpmnew to system-auth-ac, and rerun authconfig?

Thanks.
Comment 7 Tomas Mraz 2006-06-08 18:33:15 EDT
Authconfig simply cannot understand the user's changes because it cannot know
the intent of the user when he modified the system-auth file. Also how would
authconfig detect that user modified the file and so he doesn't want to change
it when authconfig is run? It could add a marker in the file which the user
would have to remove if he modified the file however it would effectively
disable the ability to configure authentication with authconfig.

My solution is not perfect however it enables user modifications (although only
limited) of the system-auth configuration and still allows using authconfig for
the main authentication configuration.

If rpm worked as it should this would be a non-issue.

You should of course keep the authconfig generated file and this is a logical
thing as by running authconfig (which is indicated by the symlink) you
effectively say that that the default config in the pam package shouldn't be used.
Comment 8 Tomas Mraz 2006-06-14 03:39:58 EDT
Also note that this sentence is wrong: "OK, so in the past there was only
/etc/pam.d/system-auth, which was merged/written by upgrades of pam or
invocations of authconfig, both of which considered the current contents of the
file during the update."

On upgrades of pam iff the contents of /etc/pam.d/system-auth in the package
changed there would have been the .rpmnew file created as well, no merge would
have been done. However the contents of /etc/pam.d/system-auth in the pam
package did not change for a very long time.
Comment 9 Tomas Mraz 2006-06-15 06:28:08 EDT
Created attachment 130962 [details]
Proposed patch to rpm

This is a proposed patch to rpm which should modify its behaviour according to
my proposal. No .rpmnew file should be created if the db and new package files
don't differ regardless of the type of the file on disk.
Comment 10 Jeff Johnson 2006-06-17 13:05:01 EDT
There are 3 comparisons involved in dbWhat:
   1) the current file on disk
   2) the old file that was originally installed
   3) the new file that is about to be installed.

The current behavior of %config(noreplace) creates a .rpmnew
file iff the current file has been changed wrto what was originally
installed.

You propose changing this behavior to a comparison between old and new,
not creating .rpmnew if old and new are identical, ignoring the file on disk.

This can/will clobber user changed files, which is unacceptable.

Otherwise the patch looks ok.
Comment 11 Tomas Mraz 2006-06-18 13:39:07 EDT
This is a complete nonsense.

Read the patch properly Jeff. The current behavior of %config(noreplace) creates
a .rpmnewfile iff the type of the current file has been changed wrto what was
originally installed.

The patch changes this behavior so when old and new (in db and in package) is
identical -> not changed, the function returns FA_SKIP -> it won't clobber
anything, it simply skips installation of the file from the package.
Comment 12 Jeff Johnson 2006-06-19 08:22:08 EDT
Sorry I missed FA_SKIP rather than FA_CREATE.

No matter what, packaging that relies on a change in rpm behavior is doomed to failure,
there is no means to do a universal upgrade of rpm. And that leads to support problem for rpm
because of the changed behavior.

The better fix -- in packaging alone -- is to isolate the file in a single package. This can be done
by having one or the other of the two pkgs install the file, or it can be done by creating a new
package that contains the file.
Comment 13 Tomas Mraz 2006-06-27 09:15:58 EDT
The current state is nothing fatal or critical and it can stay as it is. So the
packaging doesn't really rely on change in rpm behavior. However it would be
just nice and logical if rpm did what I suggest in the patch.
Comment 14 Tomas Mraz 2007-02-13 09:41:56 EST
Created attachment 147986 [details]
Improved patch

This patch handles also the opposite case when old and new packages contain
%config symlink and we have regular file on disk.
Comment 15 Jeff Johnson 2007-02-13 10:08:01 EST
Heh, that's the problem with messing with *.{rpmnew,rpmorig,rpmold} creation, there's
always another oddball corener case.

FWIW, the default one-size-fits-all implementation for file resolutions in rpm is never ever gonna
satisfy everyone, and continual adjustments to  Get It Right! are going to lead to
different behaviors between versions that are almost certainly going to make the
algorithm untrustworthy and unreliable.

Lemme see if I can merge your patch into 4.8.8 with some configuration changes to
control through configuration the elements that go into deciding "changed" (i.e. mtime
is one of the elements that noone is expecting as part of "changed") .

Comment 16 Jeff Johnson 2007-02-19 20:37:37 EST
This is the patch that I included in rpm-4.4.8-1

mtime parameterizatrion when I get a chance.

(I swear I responded to this bug once before, but perhaps I forgot "Save Changes")
Comment 17 Stijn Hoop 2007-06-19 04:22:13 EDT
Meanwhile, what do I, as unsuspecting F7 user, do with the newly created
/etc/pam.d/authconfig.rpmnew, which I got as part of the set of updates
installed *just* after installing a fresh F7?

Do note that these files differ (a lot!)

Installed versions of related packages:

authconfig-5.3.13-4.fc7
pam-0.99.7.1-5.1.fc7
rpm-4.4.2-46.fc7

So which one of the system-auth-* is correct, how do I put it in place, and why
do I have to mess with system authentication stuff by hand after updates?
Comment 18 Tomas Mraz 2007-06-19 05:01:52 EDT
You simply shouldn't do anything (eventually you can remove the .rpmnew file).
Comment 19 Jeff Johnson 2007-06-20 22:50:30 EDT
Actually you need to merge the .rpmnew into your existing file, not remove it.

That can be done in a number of ways. If changes are large, save the existing file,
and replace with the .rpmnew file. Then find what local modifications you have made
(the reason for the .rpmnew file) and merge the changes into the new version of the file.
Comment 20 Tomas Mraz 2007-06-21 08:13:53 EDT
No, in comment 18 I was talking about this concrete example of
/etc/pam.d/system-auth.rpmnew. This file is being created just because it must
be  in pam package for small systems where authconfig is not used/installed but
otherwise it is manipulated by authconfig so it has to take it over and the
.rpmnew files which are created by pam upgrades are irrelevant.

Of course for other .rpmnew files comment 19 is correct.
Comment 21 Tomas Mraz 2007-08-09 10:39:45 EDT
Panu, I saw you included the patch for multilib config conflicts. Could you
please also look at this patch?
Comment 22 Panu Matilainen 2007-08-09 14:57:04 EDT
Will do...
Comment 23 Panu Matilainen 2007-08-28 07:00:09 EDT
Fixed in rpm-4.4.2.2-rc1 in next rawhide push.

Thanks for the patch!

Note You need to log in before you can comment on or make changes to this bug.