FATAL:credentials.cc(127)] Check failed: . : Permission denied (13)

Bug #2017980 reported by Jarl
100
This bug affects 17 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
New
Undecided
Unassigned
linux-meta-nvidia-5.19 (Ubuntu)
Confirmed
Undecided
Unassigned
nvidia-graphics-drivers-510 (Ubuntu)
Confirmed
Undecided
Unassigned
ubuntu-drivers-common (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

With this kernel linux-image-nvidia-5.19 (version 5.19.0.1009.10) I experience that google-chrome crashes.
It shows

```shell
[11849:11849:0428/091628.955956:FATAL:credentials.cc(127)] Check failed: . : Permission denied (13)
Trace/breakpoint trap (core dumped)".
```

To be honest I don't think it has anything to do with google-chrome at all.
When google-chrome starts it (normally) request the system key-manager (KWallet in my case) for access to the users keys before it actually shows anything from chrome. Not even that part (the KWallet password box) shows up.

I can only reproduce this problem with this specific kernel. It should be possible to take google-chrome out of the equation by using another application that starts by request the desktop key manager for access.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: linux-image-nvidia-5.19 (not installed)
ProcVersionSignature: Ubuntu 5.15.0-1023.23-nvidia 5.15.92
Uname: Linux 5.15.0-1023-nvidia x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu82.4
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Fri Apr 28 11:23:23 2023
InstallationDate: Installed on 2016-01-08 (2666 days ago)
InstallationMedia: Kubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: linux-meta-nvidia-5.19
UpgradeStatus: Upgraded to jammy on 2022-07-21 (281 days ago)

Revision history for this message
Jarl (jarl-dk) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-meta-nvidia-5.19 (Ubuntu):
status: New → Confirmed
Revision history for this message
JanBrinkmann (jbrinkmann) wrote :

Same problem. It works, when you start "google-chrome" with the parameter "--no-sandbox" (which is not a solution, because it raises security concerns).

Revision history for this message
D (dreamjockey) wrote :

Observed with VS Code and VS Codium as well.

Revision history for this message
Jecé Xavier Pereira Neto (xavierjece) wrote :

Hello everyone, I'm still a beginner, to see if I understood, any program that generates this error if I put "--no-sandbox" will it work?

Are we going to have to keep using it like this until an update comes out or is there already something to do? Can anybody help me :)

Sincerely, Jecé Xavier.

Revision history for this message
Alexandre Paulo (1-mail-8) wrote :

Observed today on chrome. Using "--no-sandbox" as temporary fix while waiting for permanent solution.

Kubuntu 22.04
Kernel 5.19.0-1010-nvidia-lowlatency (64-bit)

Revision history for this message
Chris (mail-christianmayer) wrote (last edit ):

Running Kubuntu 22.04 (lsb_release -a: Ubuntu 22.04.2 LTS) yesterday I was asked to update these packages (packagekit role='update-packages'):
Install: linux-objects-nvidia-510-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic),
 linux-signatures-nvidia-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic),
 linux-image-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic),
 linux-modules-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic),
 linux-modules-nvidia-510-5.19.0-1010-nvidia-lowlatency:amd64 (5.19.0-1010.10, automatic),
 linux-modules-nvidia-510-nvidia-lowlatency-edge:amd64 (5.19.0-1010.10, automatic)
Upgrade: libmm-glib0:amd64 (1.20.0-1~ubuntu22.04.1, 1.20.0-1~ubuntu22.04.2),
modemmanager:amd64 (1.20.0-1~ubuntu22.04.1, 1.20.0-1~ubuntu22.04.2)

Then I shut down the machine for the night. And starting it today chrome doesn't start up with the same error message as above:

$ google-chrome
[11173:11173:0701/102011.173050:FATAL:credentials.cc(127)] Check failed: . : Keine Berechtigung (13)
Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)

(Translated in English: Permission denied - core dumped)

=> So I'm also affected by that issue since this last package update

Adding "--no-sandbox" also makes chrome run again

Changed in nvidia-graphics-drivers-510 (Ubuntu):
status: New → Confirmed
Changed in chromium-browser (Ubuntu):
status: New → Confirmed
Revision history for this message
Chris (mail-christianmayer) wrote :
Revision history for this message
Chris (mail-christianmayer) wrote :
Revision history for this message
Carlos Nogueira (carlos-nogueira04) wrote :

Same issue here as well, after an update yesterday. Running it with --no-sandbox works, but not ideal. Every other fix I've tried so far doesn't seem to work...

Revision history for this message
Jarl (jarl-dk) wrote :

I get "permission denied" on the chrome bug link https://bugs.chromium.org/p/chromium/issues/detail?id=1459821. Is there a public link for that bug?

Revision history for this message
Chris (mail-christianmayer) wrote :

I just checked the chromium bug tracker: the link is valid, but it is flagged as "Only users with EditIssue permission or issue reporter may view.".

I guess it's caused by being created from an uploaded crash report. Probably due to privacy considerations as the crash dump might contain private information.
There's also no way that I can change the permissions.

Revision history for this message
Chris (mail-christianmayer) wrote :

Coming back to this report here: as expected but now confirmed: when I boot the old kernel everything is working normally.

So the cause is *confirmed* to be the different/upgraded kernel that was installed without my request (as described in https://bugs.launchpad.net/ubuntu/+source/linux-signed-nvidia-5.19/+bug/2025538 )

Revision history for this message
Matthew (matthewf-f) wrote :

I'm seeing the same thing running Slack.
---
[****** ~]$ /bin/slack
[64844:0702/180844.731816:FATAL:credentials.cc(127)] Check failed: . : Permission denied (13)
Trace/breakpoint trap (core dumped)
---
This started after the latest 'apt update/upgrade'
The 2nd monitor connected to the laptop this is running is also no longer working. From previous posts, they appear related

Revision history for this message
CAHO (cahobad) wrote :

the same. The second monitor does not work, chrome does not start. what do you advise to do? wait or reinstall the system?

Revision history for this message
Chris (mail-christianmayer) wrote :

When booting just select an older kernel - and hope that the maintainers are quickly cleaning the mess

Revision history for this message
CAHO (cahobad) wrote :

yes i tried that. but even with the old kernel, the second monitor did not work. but chrome was running.

Revision history for this message
Matthew (matthewf-f) wrote (last edit ):

> It looks like the nvidia kernel has been reverted. However, I am still seeing the same error with Slack, and the second monitor is still not working

Sorry, the OS was still booting with nvidia low-latency kernel.
Using kernel 5.19.0-46-generic the Slack/Chrome errors are gone, but the system is not detecting the second monitor anymore

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

Removing chromium-browser as affected package because this wasn't actually verified on Chromium. If it is verified on Chromium, please revert that.

no longer affects: chromium-browser (Ubuntu)
Jarl (jarl-dk)
summary: - Chrome crashes with FATAL:credentials.cc(127)] Check failed: . :
- Permission denied (13)
+ FATAL:credentials.cc(127)] Check failed: . : Permission denied (13)
Revision history for this message
Olivier Robert (novhak) wrote :

The problem seems to come from a wrong suggestion of Nvidia proprietary driver packages, where Ubuntu logic (likely from the “ubuntu-drivers-common” package) hints towards drivers that depend on a kernel stack that’s not installed, which triggers those kernel installations as well, because dependencies.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu-drivers-common (Ubuntu):
status: New → Confirmed
Revision history for this message
Chris (mail-christianmayer) wrote :

I did an check and can confirm that the chromium-browser as installed by the usual 22.04 package is *NOT* affected.

But Google chrome well as google-chrome-beta installed by the PPA
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
do show the bug.

Revision history for this message
OrangeTanguine (orangetanguine) wrote :

I tried to launch it with --no-sandbox, and we have this return :

#/usr/bin/google-chrome-stable --no-sandbox

[69134:69156:0704/101329.358591:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[69134:69156:0704/101329.359203:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
Authorization required, but no authorization protocol specified
[69134:69156:0704/101329.453872:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[69134:69156:0704/101329.453898:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[69134:69156:0704/101329.518587:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[69134:69156:0704/101329.518613:ERROR:bus.cc(399)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
Authorization required, but no authorization protocol specified
[69170:69170:0704/101329.556446:ERROR:angle_platform_impl.cc(43)] Display.cpp:1014 (initialize): ANGLE Display::initialize error 12289: Could not open the default X display.
ERR: Display.cpp:1014 (initialize): ANGLE Display::initialize error 12289: Could not open the default X display.
[69170:69170:0704/101329.557215:ERROR:gl_display.cc(504)] EGL Driver message (Critical) eglInitialize: Could not open the default X display.
[69170:69170:0704/101329.557593:ERROR:gl_display.cc(917)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
Authorization required, but no authorization protocol specified
[69170:69170:0704/101329.559419:ERROR:angle_platform_impl.cc(43)] Display.cpp:1014 (initialize): ANGLE Display::initialize error 12289: Could not open the default X display.
ERR: Display.cpp:1014 (initialize): ANGLE Display::initialize error 12289: Could not open the default X display.
[69170:69170:0704/101329.559602:ERROR:gl_display.cc(504)] EGL Driver message (Critical) eglInitialize: Could not open the default X display.
[69170:69170:0704/101329.559707:ERROR:gl_display.cc(917)] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
[69170:69170:0704/101329.559807:ERROR:gl_ozone_egl.cc(23)] GLDisplayEGL::Initialize failed.
[69170:69170:0704/101329.562896:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization

Revision history for this message
Vic (vic-s) wrote :

I had the same issue with kernel 5.19.0-1010-nvidia-lowlatency

Using the PPA:
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

the --no-sandbox workaround works

After switching to non Nvidia kernel 5.19.17-051917-the issue has disappeared

Revision history for this message
Chris (mail-christianmayer) wrote :

Update from https://bugs.chromium.org/p/chromium/issues/detail?id=1459821 as it's not public visible:

```
@Reporter, Thanks for filing the Issue. Please find the magic signature & stack trace for the crash id# 8e7f32382b1ddc1c

Magic signature :
[Assert] sandbox::`anonymous namespace'::CheckCloneNewUserErrno

Stack Trace
Thread 0 chrome (id: 0x00010cf6)crashedMAGIC SIGNATURE THREADcontent_copy
0x0000560a0003ddb3(chrome -immediate_crash.h:146)??logging::LogMessage::~LogMessage()
0x0000560a022d31f7(chrome -logging.cc:1107)??logging::ErrnoLogMessage::~ErrnoLogMessage()
0x0000560a0619dcdd(chrome -logging.cc:1101)logging::ErrnoLogMessage::~ErrnoLogMessage()
0x0000560a01a7f08d(chrome -check.cc:198)??logging::CheckError::~CheckError()
0x0000560a0735454a(chrome -credentials.cc:126)sandbox::(anonymous namespace)::CheckCloneNewUserErrno(int)
0x0000560a01f159fc(chrome -credentials.cc:280)sandbox::Credentials::CanCreateProcessInNewUserNS()
0x0000560a01f156ff(chrome -zygote_host_impl_linux.cc:114)content::ZygoteHostImpl::Init(base::CommandLine const&)
0x0000560a01f0efc4(chrome -content_main_runner_impl.cc:382)content::(anonymous namespace)::InitializeZygoteSandboxForBrowserProcess(base::CommandLine const&)
0x0000560a01f0efc4(chrome -content_main_runner_impl.cc:1033)content::ContentMainRunnerImpl::Initialize(content::ContentMainParams)
0x0000560a0204a6bd(chrome -content_main.cc:301)content::RunContentProcess(content::ContentMainParams, content::ContentMainRunner*)
0x0000560a0204a6bd(chrome -content_main.cc:343)content::ContentMain(content::ContentMainParams)
0x0000560a020487ff(chrome -chrome_main.cc:187)ChromeMain
0x00007f29a5029d8f(libc.so.6 + 0x00029d8f)
0x00007f29a5f4c03f(ld-linux-x86-64.so.2 + 0x0003a03f)
0x00007f29a5029e3f(libc.so.6 + 0x00029e3f)
0x0000560a033991c9(chrome + 0x0000000005c281c9)_start
0x00007ffc8a640b07

As per crash ID (8e7f32382b1ddc1c) adding Internals>Core
[...]
```

Revision history for this message
Chris (mail-christianmayer) wrote :

Relaying the information from https://bugs.chromium.org/p/chromium/issues/detail?id=1459821 as it is not publicly visible:

```
Hmmm this looks like https://bugs.chromium.org/p/chromium/issues/detail?id=1365674#c8 again. I don't know why using clone(CLONE_NEWUSER ...) would return EACCES (which causes the crash). It's not documented to return that error code and I couldn't find anything in 5.19 that would change that.

Glibc doesn't seem to change the error code either.

We have a spike of crashes here recently (unsurprisingly, most of them on this 5.19.0 -1010-nvidia-lowlatency #10-Ubuntu kernel). I would call this an upstream Ubuntu bug for now.
```

Revision history for this message
Chris (mail-christianmayer) wrote :

There's also an askubuntu question about this issue: https://askubuntu.com/questions/1471028/fatalcredentials-cc127

Revision history for this message
Carlos Nogueira (carlos-nogueira04) wrote :

The workarounds here seem to work, but having to do them every time is a bit annoying. Are there no new updates on the issue ?

Revision history for this message
John Johansen (jjohansen) wrote :

This is a new feature* in Mantic (23.10) and is working as intended. It is unfortunate that applications like chrome are not handling the failed syscall in a graceful manner but application error handling, especially for applications outside of the archive, is beyond our control.

Unprivileged user namespaces going forward will be restricted as they are a security issue. They been used as part of the exploit chain in most privilege escalation attacks against Ubuntu over the last several years.

There are several workarounds available, and it is possible to disable locally if a user so desires. For more information please see the Mantic release notes https://discourse.ubuntu.com/t/mantic-minotaur-release-notes/35534

* This is actually available in Lunar (23.04) but is disabled by default and must be manually enabled with the sysctl.

Revision history for this message
Jarl (jarl-dk) wrote :

Thanks, john for a clear explanation. And thanks to the whole ubuntu team for improving the security of ubuntu in general. So it's time to bug google chrome developers...

Revision history for this message
OrangeTanguine (orangetanguine) wrote :

Thanks a lot John !
Waiting for the fix, this solution find in the Mantic release notes https://discourse.ubuntu.com/t/mantic-minotaur-release-notes/35534 works :

Disable this restriction across the entire computer for a single boot via echo 0 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns. This setting will be lost on reboot

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

From #30:
> This is a new feature* in Mantic (23.10)

The reporter and a couple of other commenters are on Jammy though, can you please clarify?

Revision history for this message
John Johansen (jjohansen) wrote :

The feature exists in the Lunar kernel (this includes 6.2 hwe kernels) but is not enabled by default, and is currently enabled by default on 6.5 kernel builds.

* If the user is using a 6.2 kernel and has enabled via the sysctl or /proc the above restriction will occur.

* If the user is using a 6.5 kernel and has NOT disabled via sysctl or /proc the above restriction will occur.

This feature is not dependent on he userspace but on the kernel in use.

There are 3 ways to address the above issue
1. Application Level
   Install or create a profile for the application

2. System Level, temporarily (until reboot) disable via
   echo 0 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns

3. System Level, disable via
   sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

OR
    add a new file /etc/sysctl.d/60-apparmor-namespace.conf with contents

        kernel.apparmor_restrict_unprivileged_userns=0

    and reboot.

Going forward the 6.5 kernel is going to move to the feature is going to be tweaked so that the userspace will have to enable it. The apparmor package in mantic will enabled it. This will prevent installation of the 6.5 kernel or HWE build variants from automatically enabling the feature on older releases.

tags: added: oem-priority originate-from-2031849 somerville
Revision history for this message
Alex Murray (alexmurray) wrote :

This is planned to be fixed in the apparmor package itself in mantic by proving a suitable profile for chrome - something like the following in /etc/apparmor.d/opt.google.chrome.chrome

abi <abi/4.0>,

include <tunables/global>

/opt/google/chrome/chrome flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/opt.google.chrome.chrome>
}

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.