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

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

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

Observed with VS Code and VS Codium as well.

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.

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)

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

Related (but not duplicate) is bug https://bugs.launchpad.net/ubuntu/+source/linux-signed-nvidia-5.19/+bug/2025538

Chrome bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=1459821

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...

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?

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.

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 )

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

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

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

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

> 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

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

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.

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

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.

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

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

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
[...]
```

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.
```

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

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 ?

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.

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...

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

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?

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.

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>
}

This bug is awaiting verification that the linux-azure-6.5/6.5.0-1007.7~22.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-azure-6.5' to 'verification-done-jammy-linux-azure-6.5'. If the problem still exists, change the tag 'verification-needed-jammy-linux-azure-6.5' to 'verification-failed-jammy-linux-azure-6.5'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the linux-aws-6.5/6.5.0-1008.8~22.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-aws-6.5' to 'verification-done-jammy-linux-aws-6.5'. If the problem still exists, change the tag 'verification-needed-jammy-linux-aws-6.5' to 'verification-failed-jammy-linux-aws-6.5'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

Comment #34 , jjohansen ,
sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
worked for me amazingly and allowed me to start my viber 21.0.0.1 again!
Thank you a lot!

it started crashing after I upgraded my Linux package from 6.5.0-14.14 to 6.6.0-14.14 on Jan 05th and rebooted.
I am testing Ubuntu Noble 24.04 , soon to be released.
Hope this bug to be fixed at least by Viber/Chrome developers until April 2024