Kernel 5.16.1-1 PAM issue after upgrading from 20220101 to 20220121
I just upgraded from build 20220101 to 20220121. I use pam_cifscreds.so but pam-config still does not have built in support for it so for the last 2 years (when I started using TW ) whenever a new build updates pam I have to manually reapply my changes. I add the following to /etc/pam.d/common-auth auth optional pam_cifscreds.so I add the following to /etc/pam.d/common-session session required pam_keyinit.so session optional pam_cifscreds.so host=FILESERVER and then I reboot. I have 2 mounts in fstab for the cifs shares and they use the multiuser option. Everything has worked fine for the last 2 years after I reapply the above changes to PAM but after updating to build 20220121, and applying those changes and rebooting when I try to login to the GUI desktop the system either hangs and does not login to the desktop or the login screen is redisplayed after a minute. If I reboot using the previous kernel I was using (5.15.12-1) with the above pam.d config changes made, then I am able to login without issue and can access the cifs shares without issue so the issue appears to be with the 5.16.1-1 kernel. If I comment out the pam_keyinit.so line added in common-session and reboot using the 5.16.1-1 kernel then I am able to login to the GUI now. After logging in I use 'cifscreds -u joe FILESERVER' and enter my password and it completes successfully but when I try to access the cifs mounted share the following entries are in the system journal kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page As mentioned, If I rebooting using the 5.15.12-1 kernel with the 3 above lines added to the pam configs everything works fine. If I reboot using the 5.15.12-1 kernel but comment out the pam_keyinit.so line (which causes kernel 5.16.1-1 to have the null pointer issue) and then issue the cifscreds command after logging in I am also able to access the cifs shares without issue. Is this a known issue? Has it been fixed in a TW build after 20220121 ?
On 31.01.22 16:25, Joe Salmeri wrote:
After logging in I use 'cifscreds -u joe FILESERVER' and enter my password and it completes successfully but when I try to access the cifs mounted share the following entries are in the system journal
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page
This is a kernel bug. No matter what you are doing as a normal user must not crash the kernel.
As mentioned, If I rebooting using the 5.15.12-1 kernel with the 3 above lines added to the pam configs everything works fine.
As this is clearly a regression from 5.15 to 5.16, filing a bug for the openSUSE kernel team on https://bugzilla.opensuse.org/ will be your easiest way to get this fixed. I do not use CIFS, so I cannot help with the actual bug, but from experience I know that a good bugreport for the kernel team (quote all the journal lines around the BUG: message) is your way to get this fixed. Good luck :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Thanks Stefan. I just submitted the followingbug report and included all the detailed journal messages that occur after the issue occurs. https://bugzilla.opensuse.org/show_bug.cgi?id=1195360
In case anyone else runs into this issue it has been fixed. A new kernel is available here and will appear in TW in "about" a week I was told. https://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/ke... I have installed the newer kernel and tested and verified that the problem is resolved. Thanks Stefan for your assistance!
On Wed, 2022-02-02 at 15:15 +0000, Joe Salmeri wrote:
In case anyone else runs into this issue it has been fixed.
A new kernel is available here and will appear in TW in "about" a week I was told.
for reference: the kernel with the fix has been submitted to Tumbleweed in https://build.opensuse.org/request/show/950876 (kernel 5.16.5) It is currently passing through staging. The 'one week' sounds about right as a target. Cheers, Dominique
Hi Joe, Am Donnerstag, 3. Februar 2022, 09:44:36 CET schrieb Dominique Leuenberger / DimStar:
On Wed, 2022-02-02 at 15:15 +0000, Joe Salmeri wrote:
In case anyone else runs into this issue it has been fixed.
A new kernel is available here and will appear in TW in "about" a week I was told. for reference: the kernel with the fix has been submitted to Tumbleweed in https://build.opensuse.org/request/show/950876 (kernel 5.16.5)
It is currently passing through staging. The 'one week' sounds about right as a target.
Next time, may I suggest following procedure: * locate repo file of the repo in question, in this case: https://download.opensuse.org/repositories/Kernel:/stable/standard/Kernel:st... * add that repo to your local bouquet zypper ar -r https://download.opensuse.org/repositories/Kernel:/stable/standard/Kernel:st... (if you're not tight on your /var partition, *and* want to keep older packages from *that* repo, consider -k as well, especially, if you're reusing such repos from a global share on your network ;-) ) * search the kernel, you want zypper se -s kernel-default * install it, in this case, that would have been: zypper in kernel-default-5.16.5-2.1.g5277fb2 * done If you add a few more latest-x items to /etc/zypp/zypp.conf:multiversion.kernels, you increase the number kernels, the kept installed. Next time, you do a zypper dup, you get a current Kernel:stable build. Stop using new builds of Kernel:stable kernels with: zypper mr -d Kernel_stable Making use of the repo concept is a real game changer in this regard. Now add priorities and locks to the sauce, and find yourself on the next level of success. Cheers, Pete -- Life without chameleons is possible, but pointless.
On Mon, 2022-02-07 at 19:17 +0100, Hans-Peter Jansen wrote:
Making use of the repo concept is a real game changer in this regard.
Now add priorities and locks to the sauce, and find yourself on the next level of success.
I fully agree, with some caveats: 1) Over time, the auxiliary repos tend to accumulate such that it's hard to stay on top of things (why did I add _that_ repo again?), in particular on Leap; 2) Using aux repos is officially discouraged. So by using them (IMO Leap is basically unusable without them), you keep violating official policy, and risk getting told "you're not supposed to do this" when you report an issue. Regards Martin
Hi Stefan, What do you use to share files on your network? I am using Samba because I have Windows and Linux clients. Is there a better option that I have missed? Thanks!
On 31.01.22 20:45, Joe Salmeri wrote:
Hi Stefan,
What do you use to share files on your network? I am using Samba because I have Windows and Linux clients.
Short answer: I don't share files on my network ;-) Longer answer: For Linux clients (most of my machines), a central NFS server at home and a NIS (YP) automounter setup is good enough. On the same server, there is an apache web server which is providing the same directories that the NFS server is sharing via http. So whenever I need to share e.g. a big installation package downloaded on linux to a windows VM, I can put it onto the NFS share from Linux and then download with the browser in Windows. If I need to export somehting from windows back to the other machines, I usually just use ssh (putty / pscp or such) to copy it onto the server, from where it can be retrieved again via NFS / HTTP. OR... i just move it around via my local (on the same server) owncloud installation OR, sometimes, just via Google drive.
Is there a better option that I have missed?
I would not consider my setup "better" at all. It is all unauthenticated (old style NFS3, NIS is not really "secure" IIUC, http download without credentials, all directories more or less world-readwriteable) and nothing that a non-technical user can use easily. I think I even have a samba server running on that server machine for some reason I forgot (maybe windows printing?), but I just never got around to understanding how to mount samba shares on linux and in the past it was said to perform worse than NFS. The setup has evolved over 20 years and I guess it will last another 20 years and then I'll probably no longer care that much ;-) So use whatever fits you well. Maybe also creating a bugreport pam-config, so that you do not need to manually fix your setup after every update would be appropriate, as a tool that breaks your config every time is clearly broken ;-) Best regards, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Stefan, Thanks for your detailed answer. I went with Samba because I am sharing between Linux and Window machines (some real, some VMs). Originally the file server was Windows but it has been TW for a while now. All access to any of the shared items is authenticated and locked down pretty tight. The setup I have was pretty straightforward to setup but when I initially set it up the linux users had to enter their user/pswd every time whereas Windows passed the credentials to the server and did not require reentering. Then I learned that pam could be configured to do this using the pam_cifscreds module but pam-config did not having built in support for it so I have to do the manual config and fix when updates remove it. Back in 12/31/2020 I did submit a request for pam_cifscreds support but the issue still sits open and nothing has occurred since I submitted it. Here's the request... https://github.com/SUSE/pam-config/issues/7 Should I have submitted to bugzilla.opensuse.org instead? Thanks!
On Tue, Feb 01, Joe Salmeri wrote:
Here's the request...
https://github.com/SUSE/pam-config/issues/7
Should I have submitted to bugzilla.opensuse.org instead?
Provide a rule with which the PAM module works in all scenarios. This includes our LDAP, kerberos and similar configurations. This would help much more. Because the pam-config Author has no clue about all this special PAM modules not part of Linux-PAM ;) PAM configuration is very tricky and putting a module in the wrong place can mean that you have a big security hole. That's why adding unknown modules with an unuseable docu like pam_cifscreds is next to impossible. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
Hi Thorsten,
Provide a rule with which the PAM module works in >> all scenarios.
Sorry but I don't know how to do that and also don't use LDAP or kerberos. I'm confused when you say pam_cifscreds is an unknown module as it is installed from the main TW repository? If there a better way to achieve what I'm trying to accomplish? The main server is running TW and Samba with shares created that are used by Linux and Windows clients. Linux clients mount the shares in /etc/fstab with the multiuser mount option and a credentials file for a user which has very limited permissions to the share. Then when a Linux client user accesses the mountpoint for the share they get their own session ( because of multiuser mount option ) allowing them access to the files which they have permission on. Windows clients map to the shares in the login script and because of Windows passthru authentication they map to the shares using their windows user/password which is the same as the user/password setup using smbpasswd on the Linux server. The ONLY reason I am using pam_cifscreds is because that was the only method I could find to have the Linux client use the cached credentials ( like Windows is doing ) to access the shares without the users having to enter a user/password each time. If there is a better way to accomplish this please let me know. THANKS!
On Wed, Feb 02, Joe Salmeri wrote:
Provide a rule with which the PAM module works in >> all scenarios.
Sorry but I don't know how to do that and also don't use LDAP or kerberos.
I'm confused when you say pam_cifscreds is an unknown module as it is installed from the main TW repository?
I didn't say that pam_cifscreds is an unknown module. If you mean that I don't know it: TW has 30.000 packages or so. So the chances that I don't know a package are really high. It's badly documented and can only be added to pam-config if somebody explains me, how the stack needs to look like in all scenarios pam-config supports. I will not add a module where the result only works in some few cases and else is a security risk for the others. I don't know this module, and I don't use it and I don't use LDAP or kerberos. So I cannot find out how to configure it and test it. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
Hi Thorsten,
That's why adding unknown modules with an unuseable docu like pam_cifscreds is next to impossible.
Sorry when you said that I took it to mean that you were saying that pam_cifscreds is an unknown module. The bottom line is that pam_cifscreds is the only way I've currently found to accomplish what I described above. If there is a better way to have a Linux client use cached credentials to access a Samba share on another machine instead of having to enter then each time? If so, please share that with me and I will happy switch to using that method. THANKS!
On Wed, 2022-02-02 at 16:41 +0100, Thorsten Kukuk wrote:
On Wed, Feb 02, Joe Salmeri wrote:
Provide a rule with which the PAM module works in >> all scenarios.
Sorry but I don't know how to do that and also don't use LDAP or kerberos.
I'm confused when you say pam_cifscreds is an unknown module as it is installed from the main TW repository?
I didn't say that pam_cifscreds is an unknown module. If you mean that I don't know it: TW has 30.000 packages or so. So the chances that I don't know a package are really high.
It's badly documented and can only be added to pam-config if somebody explains me, how the stack needs to look like in all scenarios pam-config supports. I will not add a module where the result only works in some few cases and else is a security risk for the others. I don't know this module, and I don't use it and I don't use LDAP or kerberos. So I cannot find out how to configure it and test it.
No offense intended, but _you_ needing to understand every module sounds like a badly scalable design. It should be possible (and actually, mandatory for openSUSE PAM packages) to provide some sort of "plugin" for pam-config which describes the capabilities and dependencies of the module. Best regards, Martin
Hi Martin, Are you aware of a better way to accomplish what I am currently doing via pam_cifscreds? In simple terms, when a Windows client computer connects to a share that is hosted on another Windows computer OR on a share hosted on Linux computer it will pass the current users credentials to the machine hosting the share ( Windows OR Linux) and as long as the user accounts and passwords are the same it works transparently. This does NOT require a Windows domain to work and I have setups like that working for 20+ years. On Windows to Windows connections you just setup the same user/pswd on each computer and it is called passthru authentication. When a Windows client connects to a Linux Samba share, it also works transparently too as long as you have setup the samba users using smbpasswd with the same user/pswds. For a Linux client connecting to a Linux Samba share, without pam_cifscreds you have to do a cifscreds add -u <user> <host-with-share> each time which does not persist a logoff or reboot. pam_cifscreds caches the login information and then uses that to authenticate to the share hosted on a Windows or Linux computer. When it is a Linux client and you are using the mount -t cifs with the multiuser option this allows each user on the Linux client machine to access share via their own credentials and permissions. The main issue is that pam-config does not support pam_cifscreds so you have to manually configure it which gets overwritten when TW updates. Seems to me like when a mount -t cifs with the multiuser option is done that the system should recognize that it needs to use the current users cached credentials to access the resource. Wonder if that would be worth a bug report since it appears that pam-config probably won't get updated. When I originally setup this environment I found LOTS and LOTS of discussions on the Internet about people trying to accomplish a setup like mine and finding the solution that I am using was not easy to find but was easy once I found it. Do you know of a better way to accomplish what I want that I have missed? Thanks! Joe
On Thu, 2022-02-03 at 15:18 +0000, Joe Salmeri wrote:
Hi Martin,
Are you aware of a better way to accomplish what I am currently doing via pam_cifscreds?
Have a look at the comments in /etc/auto.smb, maybe. It supports an autofs mechanism which works either with Kerberos or with statically stored user credentials. I used that in the past quite successfully, but I haven't for a long time. Martin
On Tue, 08 Feb 2022, 10:27:26 +0100, Martin Wilck wrote:
On Thu, 2022-02-03 at 15:18 +0000, Joe Salmeri wrote:
Hi Martin,
Are you aware of a better way to accomplish what I am currently doing via pam_cifscreds?
Have a look at the comments in /etc/auto.smb, maybe. It supports an autofs mechanism which works either with Kerberos or with statically stored user credentials.
I used that in the past quite successfully, but I haven't for a long time.
agreed, however it does not currently work on Tumbleweed: <https://bugzilla.opensuse.org/show_bug.cgi?id=1191543> Bug has been accepted, but there is no activity anymore. I solved it by rebuilding Leap 15.3's autofs package for Tumbleweed.
Martin
Cheers. l8er manfred
On Thu, Feb 03, Martin Wilck wrote:
On Wed, 2022-02-02 at 16:41 +0100, Thorsten Kukuk wrote:
On Wed, Feb 02, Joe Salmeri wrote:
Provide a rule with which the PAM module works in >> all scenarios.
Sorry but I don't know how to do that and also don't use LDAP or kerberos.
I'm confused when you say pam_cifscreds is an unknown module as it is installed from the main TW repository?
I didn't say that pam_cifscreds is an unknown module. If you mean that I don't know it: TW has 30.000 packages or so. So the chances that I don't know a package are really high.
It's badly documented and can only be added to pam-config if somebody explains me, how the stack needs to look like in all scenarios pam-config supports. I will not add a module where the result only works in some few cases and else is a security risk for the others. I don't know this module, and I don't use it and I don't use LDAP or kerberos. So I cannot find out how to configure it and test it.
No offense intended, but _you_ needing to understand every module sounds like a badly scalable design. It should be possible (and actually, mandatory for openSUSE PAM packages) to provide some sort of "plugin" for pam-config which describes the capabilities and dependencies of the module.
It does not matter if I understand every module or the one writing the plugin. Somebody needs to know how this module needs to be configured in conjuction with all other PAM modules pam-config supports. And if somebody is doing it himself and provides a Module for pam-config, or if he explains it to me so that I can add it: I don't care. But in 99% of the cases people can only tell me how it works in their special environment, but not in a generic way. Between, pam-config has something like a "plugin" concept: it's one C file/struct per module. Several people had the same idea like you and wanted to write a plugin infrastructure for pam-config: nobody come ever back with something, not even a limited idea how this could look like. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
Am Mittwoch, 2. Februar 2022, 16:12:26 CET schrieb Joe Salmeri:
The ONLY reason I am using pam_cifscreds is because that was the only method I could find to have the Linux client use the cached credentials ( like Windows is doing ) to access the shares without the users having to enter a user/password each time.
If there is a better way to accomplish this please let me know.
Let's try that one. Usually you only need access from Linux to Windows occasionally, and chances are you just want to copy stuff around. You never mentioned the DE, you're using. I'm a KDE junkie, so here's my 2¢. If accessing Windows shares from dolphin (and all KDE aware programs) is sufficient, then install pam_kwallet, get your kwallet password in sync with your login password, and access your shares with: smb://user@host/ or smb:// domain\user@host/. Start in dolphin, you will be asked for credentials *one* time (assuming you tick "keep password"). Add a shortcut in the "foreign device" bar (by drag'n'drop). Give it a sound name (and icon) via properties. Thanks to pam_kwallet, your credentials are available without entering your password twice (login and kwallet). Best, Pete -- Life without chameleons is possible, but pointless.
On Mon, Jan 31, 2022 at 12:26 PM Joe Salmeri <jmscdba@gmail.com> wrote:
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page
You are doing nothing wrong, it is the cifs kernel module doing something extremely nasty and your CPU is watching your back and stopping it right before it happens.
Thanks for your reply Cristian. I am a developer and understand what the null pointer means and was trying to find out if this is a known issue. I could not find any other reports so I submitted the bug report with the details.
participants (9)
-
Cristian Rodríguez -
Dominique Leuenberger / DimStar -
Hans-Peter Jansen -
Joe Salmeri -
Manfred Hollstein -
Martin Wilck -
Martin Wilck -
Stefan Seyfried -
Thorsten Kukuk