Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chrome on Ubuntu Fails to Respect --crash-dumps-dir and --disable-crash-reporter Flags #114

Open
jasonolmstead33 opened this issue Feb 27, 2024 · 4 comments

Comments

@jasonolmstead33
Copy link

Description:

We are experiencing an issue with Google Chrome on an Ubuntu system, where Chrome attempts to write or create directories under /var/lib/${USER_NAME}, leading to an EACCES (Permission Denied) error. This behavior occurs despite running Chrome under a specific user account with restricted permissions.

Steps to Reproduce:

  1. Log in or switch to a non-root user account on an Ubuntu system.
  2. Launch Google Chrome from the terminal using the user account, including either the --crash-dumps-dir flag to specify a custom directory for crash reports or the --disable-crash-reporter flag to disable the crash reporter feature.
  3. Observe that Chrome attempts to write or create directories under /var/lib/${USER_NAME}, resulting in an EACCES error and browser crashing

Expected Behavior:

Chrome should either:
a. Skip using the crash reporter entirely and log a message indicating that the crash reporter is not in use, or
b. Respect the --crash-dumps-dir flag to use the specified directory for crash reports, or
c. Respect the --disable-crash-reporter flag to disable the crash reporter without attempting to write to unauthorized directories.

Actual Behavior:
Chrome attempts to access /var/lib/${USER_NAME}, resulting in permission denied errors, even when the --crash-dumps-dir or --disable-crash-reporter flags are used and crashes

Environment:
Operating System: Ubuntu 20.04
Chrome Version: 122.0.6261.57
Browser: Chrome
Note I used the @puppeteer/browsers module to install chrome browser

Additional Information:
This issue poses a challenge for running automated tests under restricted user accounts, where directory access permissions are limited.
No relevant policy changes or configurations outside of the default install were applied that might influence Chrome's behavior in this context.

@thiagowfx
Copy link
Contributor

In principle, nothing on CfT changes the behavior of crash reporting. Can you also reproduce this with regular Google Chrome and/or with Chromium?

@tinybutch
Copy link

I agree this is complete trash that Google Chrome generates multiple .dmp files in Crashpad directory without any possibility to disable this.

Shame on you Google Big Brother Malware Corporation!

@jredl-va
Copy link

jredl-va commented Aug 17, 2024

Well..I'm glad I'm not the only one who is finding this frustrating...

The crash reporting for long running containers that are running chromium for browser automation testing get littered with these errors and disk usage is eventually consumed...

We've opted to add a cron to the containers that flushes the crash reporting every 5 minutes. Leaving this here in the event someone else finds this useful. Assuming that cron is available.

dockerfile extension.

# Cleanup crash reports
COPY cleanup_crash_reports.sh /usr/local/bin/cleanup_crash_reports.sh
RUN chmod +x /usr/local/bin/cleanup_crash_reports.sh

# Add the cron job
RUN (crontab -l ; echo "*/5 * * * * /usr/local/bin/cleanup_crash_reports.sh") | crontab -

cleanup script

#!/bin/bash

# Define the directory where Chrome crash reports are stored
CRASH_REPORTS_DIR="$HOME/.config/google-chrome/Crash Reports"

# Remove all files in the crash reports directory
if [ -d "$CRASH_REPORTS_DIR" ]; then
  rm -rf "$CRASH_REPORTS_DIR"/*
fi

@avarnell-te
Copy link

I am a little surprised and confused by this, isnt chrome-for-testing branched off of chromium where crashdumps are disabled unless compiled differently? I do not see crash dumps enabled when I visit chrome://crashes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants