Bug 644698

This can be worked around by using pam-config command line utility....

That is to say by modifying the pam-config utility...

I did make the necessary modifications to pam-config for my personal situation in a linkpac on my OBS account. It strikes me as a little strange this is a system written in C. I know it comes from upstream but is pam-config even necessary? YaST could have it's own module and geld pam-config completely, it doesn't seem to do anything majorly useful except keep the modules in the right order and prevent you adding conflicting ones, the configuration it performs could easily be done with a text editor, and IMHO pam-config should be written as shell scripts, it's overkill to do something so simple with a full-blown C package.

Unfortunately, it also prevents you adding non-standard modules. If it was kept around maybe it should ignore what it doesn't understand instead of erasing them - but this isn't really a SUSE issue since I don't think pam-config originates there (although it's the first distro I came across it in).

Reassigning to yast2-pam maintainer.

YaST actually uses pam-config tool. 

Which YaST module do you mean was used? Or, which part of AutoYaST configuration was it?

Which files were rewritten? Do you have the log file from the installation? (http://en.opensuse.org/openSUSE:Bugreport_YaST)

I can't remember what I was doing and I'm not entirely comfortable giving away everything YaST has done on my system by sending a complete log. I would have thought you would know when YaST calls pam-config? I am aware that YaST uses this tool to perform this job, as above I made a linkpac so it stops breaking my pam-config :)

Sorry I can't be more helpful on this occasion, but YaST frequently does a lot of unnecessary things, such as if you install a package it will just go ahead and reconfigure gnome and all sorts of unrelated things. Not a problem (albeit a waste of time) if those things are set up OK - I don't think I need to submit my YaST log as it shouldn't be hard to find when YaST calls pam-config. Perhaps pam-config was upgraded and this is what caused it to be re-run? I don't know but it's not very hard with tools like ctags available to work out when YaST calls pam-config is it?

And perhaps it wasn't YaST at all - I haven't checked the pam-config RPM but perhaps when it is upgraded it decides to re-run itself.

Either way, having it remove entries it doesn't understand is completely wrong. If the user knows how to edit their PAM files they probably know what they are doing and don't need pam-config to go and erase their changes unless they did something blatently stupid like put unix and unix2 in there, checking for which seems to form a large part of the pam-config package.

You can go ahead and close it if you really think you need more info, but it's a feature request to get rid of pam-config and replace it with something in YaST itself so you can configure PAM modules with YaST (including custom ones) or at least patch it to not erase things it doesn't understand. I've already modified it for myself so it's not a problem for me but, erasing PAM modules the user chooses to add to their configuration is a complete mistake IMHO. There's "hand-holding" and "crippling baby-sitting". This falls into the latter category.

And if they completely broke their system with a screwed up pam config they probably know how to boot with init=/bin/bash too - I really can't see any defence for destroying a users PAM config.

I know in what occasions YaST calls pam-config, but these are different calls. As I assume it was just one of those calls that broke your user setting, I'm asking you for the help.

And your case was special with your custom files before, but as we do not know which files were modified, we could hardly guess what was broken.

To your last paragraph: this would be even more problematic. As you know, automatic changes to PAM files are not easy, so if YaST should work even more high level than pam-config, it would have to use more magic and it would probably fail in more situations. On the other hand, if YaST should work more low-level on PAM files, that would mean more user input would be needed and most users do not know about this stuff so we'd scare them.

Reassigning to pam-config maintainer, maybe he can help you...

pam-config write /etc/pam.d/common-***-pc files. These files are exclusive for pam-config. If you want to do your own configuration, please remove the symlink from common-*** to common-***-pc and create your own common-*** files.

pam-config detect that common-*** is not a symlink and warn you, that the configuration you created with pam-conflig is not used. But in this case this is, what you want.

I created a Feature to enhance the docu about this.

OK, that's good. Would you consider also putting it into the comments of the auto-generated pam-config files along with the warning they will be overwritten? Something like "*-pc files are exclusive to pam-config, if you want to do your own custom configuration, remove the symlinks to them and create your own files".

?