[snap] Cannot run chromium as user www-data because home directory is /var/www

Bug #1849371 reported by RichardNeill
42
This bug affects 5 people
Affects Status Importance Assigned to Milestone
snapd
Confirmed
Undecided
Unassigned
chromium-browser (Ubuntu)
Confirmed
Undecided
Unassigned
snapd (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Since the move to snap, and upgrade to 19.10, I can no longer use headless-chromium to do automated conversions.

The script, as currently run by Apache (user www-data) as a back-end server process is:

/usr/bin/timeout 60 chromium-browser --no-sandbox --headless --disable-gpu --window-size=2048,1448 --screenshot='dummy.pdf' 'http://localhost/[...]' 2>&1 2>&1

This returns error 1, with:

dconf-CRITICAL **: 19:41:17.958: unable to create directory '/var/www/.cache/dconf': Permission denied. dconf will not work properly.

WARNING: cannot create user data directory: cannot create "/var/www/snap/chromium/899":
mkdir /var/www/snap: permission denied
Sorry, home directories outside of /home are not currently supported.
See https://forum.snapcraft.io/t/11209 for details.

So... how are we supposed to use scripted Chrome for headless work, when the snaps don't support it?
This is a major blocker for me, as it completely destroys my ability to do any development work, because the build-toolchain for selftests relies on the ability of chrome to operate headless.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: chromium-browser 77.0.3865.120-0ubuntu1~snap1
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
CurrentDesktop: MATE
DRM.card0-DP-1:
 enabled: disabled
 dpms: Off
 status: disconnected
 edid-base64:
 modes:
DRM.card0-DP-2:
 enabled: disabled
 dpms: Off
 status: disconnected
 edid-base64:
 modes:
DRM.card0-HDMI-A-1:
 enabled: enabled
 dpms: On
 status: connected
 edid-base64: AP///////wBMLToINDAxMCsWAQOANCB4KgHxoldSnycKUFS/74BxT4EAgUCBgJUAlQ+pQLMAKDyAoHCwI0AwIDYABkQhAAAaAAAA/QA4Sx5REQAKICAgICAgAAAA/ABTTVMyNEE0NTAKICAgAAAA/wBINE1DQTEzMzYyCiAgAQkCAQQAAjqA0HI4LUAQLEWABkQhAAAeAR0AclHQHiBuKFUABkQhAAAeAR0AvFLQHiC4KFVABkQhAAAejArQkCBAMSAMQFUABkQhAAAYjArQiiDgLRAQPpYABkQhAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0g==
 modes: 1920x1200 1920x1080 1600x1200 1680x1050 1280x1024 1280x1024 1440x900 1440x900 1280x960 1280x800 1152x864 1280x720 1280x720 1280x720 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 720x576 720x480 720x480 640x480 640x480 640x480 640x480 640x480 720x400
DRM.card0-HDMI-A-2:
 enabled: enabled
 dpms: On
 status: connected
 edid-base64: AP///////wAlpVNWODYxMB0NAQOBKR//6uWVpVhMlyYeUFS/7wCBgKlAMVlFWWFZgZkBAQEBSD9AMGKwMkAAwAMAmDIRAAAeAAAA/QA4VR9cEQAKICAgICAgAAAA/wBCSEZGS0I2MzAwMTY4AAAA/ABMMjBDTQogICAgICAgAMU=
 modes: 1600x1200 1280x1024 1280x1024 1280x1024 1024x768 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 800x600 640x480 640x480 640x480 640x480 640x480 720x400
DRM.card0-HDMI-A-3:
 enabled: enabled
 dpms: On
 status: connected
 edid-base64: AP///////wAlpVNWNjIyMB0NAQOBKR//6uWVpVhMlyYeUFS/7wCBgKlAMVlFWWFZgZkBAQEBSD9AMGKwMkAAwAMAmDIRAAAeAAAA/QA4VR9cEQAKICAgICAgAAAA/wBCSEZGS0I2MzAwMjI2AAAA/ABMMjBDTQogICAgICAgAM8=
 modes: 1600x1200 1280x1024 1280x1024 1280x1024 1024x768 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 800x600 640x480 640x480 640x480 640x480 640x480 720x400
Date: Tue Oct 22 19:48:51 2019
DiskUsage:
 Filesystem Type Size Used Avail Use% Mounted on
 /dev/sdb1 ext4 1.8T 491G 1.3T 29% /home
 tmpfs tmpfs 32G 927M 31G 3% /dev/shm
 /dev/sdb1 ext4 1.8T 491G 1.3T 29% /home
InstallationDate: Installed on 2017-02-03 (991 days ago)
InstallationMedia: Ubuntu-MATE 17.04 "Zesty Zapus" - Alpha amd64 (20170125)
MachineType: System manufacturer System Product Name
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic root=UUID=6ef42be7-d431-4d0d-bc57-79f7a96980ef ro
Snap.ChromeDriverVersion:
 ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (failed to map segment from shared object): ignored.
 ChromeDriver 77.0.3865.120 (416d6d8013e9adb6dd33b0c12e7614ff403d1a94-refs/branch-heads/3865@{#884})
Snap.ChromiumVersion:
 ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (failed to map segment from shared object): ignored.
 Chromium 77.0.3865.120 snap
SourcePackage: chromium-browser
UpgradeStatus: Upgraded to eoan on 2019-10-21 (0 days ago)
dmi.bios.date: 05/16/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 3805
dmi.board.asset.tag: Default string
dmi.board.name: Z170 PRO GAMING
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3805:bd05/16/2018:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ170PROGAMING:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

Revision history for this message
RichardNeill (ubuntu-richardneill) wrote :
Revision history for this message
Olivier Tilloy (osomon) wrote :

Headless chromium as a snap works.

What doesn't work is running it as user www-data, which has $HOME set to /var/www.

Try exporting HOME to something the snap can write to, or alternatively run chromium with the --user-data-dir= argument.

Please share the results here. Thanks!

summary: - headless chromium broken (as a consequence of snap)
+ Cannot run headless chromium as user www-data
summary: - Cannot run headless chromium as user www-data
+ [snap] Cannot run headless chromium as user www-data
Revision history for this message
RichardNeill (ubuntu-richardneill) wrote : Re: [snap] Cannot run headless chromium as user www-data

Thanks for the suggestion, and you're right, your summary is better.

I tried the following (with various permutations).

sudo su -l -s /bin/bash www-data
mkdir /tmp/chromium-home

HOME=/tmp/chromium-home /usr/bin/timeout 60 chromium-browser --no-sandbox --headless --disable-gpu --window-size=2048,1448 --screenshot='/tmp/dummy.pdf' --user-data-dir=/tmp/chromium-home 'http://localhost/...'

and this complains in a different way:
  Sorry, home directories outside of /home are not currently supported.
  See https://forum.snapcraft.io/t/11209 for details.

Before the snap change was made, chromium would run headless without (I think) actually needing any writeable directory at all.

Revision history for this message
Olivier Tilloy (osomon) wrote :

The system-wide /tmp is not accessible by strictly-confined snaps, so /tmp/chromium-home won't work either.

In any case this looks like a limitation hard-coded in snapd, which won't create $SNAP_USER_DATA if $HOME is not in /home. So this is not specific to the chromium snap. I'll add a snapd task to the bug.

As a workaround (I realize this is less than ideal), could you maybe create a user with a home directory in /home just for this purpose, and have have your server process run chromium as this user?

summary: - [snap] Cannot run headless chromium as user www-data
+ [snap] Cannot run chromium as user www-data because home directory is
+ /var/www
Changed in chromium-browser (Ubuntu):
status: New → Confirmed
Revision history for this message
Olivier Tilloy (osomon) wrote :

Snapd team: this is admittedly a corner case, but users with a home directory outside of /home might want to run snaps (especially CLI tools as e.g. user www-data). Would it be feasible to add support for this in snapd?

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

The limitation on HOME is well known and for now has no workaround other than to bind mount whatever custom home directory to /home/$LOGNAME.

I'm marking this as confirmed but I think it's going to be de-duplicated in another pass. There's already a bug for this.

Changed in snapd:
status: New → Confirmed
Changed in snapd (Ubuntu):
status: New → Confirmed
Revision history for this message
RichardNeill (ubuntu-richardneill) wrote :

The snap confinement also seems to create a number of other problems. I've also observed:

* Webmail - if I receive an attachment of certain types (libreoffice is broken; pdf is OK), then I get a "please confirm you want to allow chromium to open this file" dialog every single time.

* password manager (save passwords) is broken - it won't remember passwords I saved, nor does it remember my preference not to save the passwords for web-development on localhost, but prompts every time.

* cross site logins are broken (sign into gmail for work, and other sites that use that gmail auth just fail).

* some extensions break (e.g. the JSONViewer is silently-non-functional.)

All of these are fixed if I download and unzip the binary from here:
https://download-chromium.appspot.com/ - though it sacrifices the entire point of running a distro.

I understand the rationale for saving developer time, but this is really broken for me and my company. If it would help, we'd happily be invoiced £500 by the Ubuntu project if you could go back to the deb build - even if you chose only to ship alternate releases.

Revision history for this message
ts (toto-23) wrote :

+1 we're willing to pledge €500 (upon invoice) if either snap is repaired or standard packages managed through a system that isn't broken (dpkg/apt).

Revision history for this message
Olivier Tilloy (osomon) wrote :

> * Webmail - if I receive an attachment of certain types (libreoffice
> is broken; pdf is OK), then I get a "please confirm you want to allow
> chromium to open this file" dialog every single time.

This is working as intended. This may seem a bit annoying, but strict confinement means it is important for snapd to confirm that the user really intended to open an external file, as opposed to an action triggered automatically by the app.

> * password manager (save passwords) is broken - it won't remember
> passwords I saved, nor does it remember my preference not to save the
> passwords for web-development on localhost, but prompts every time.

This was bug #1849160 that is now fixed. In case the update didn't resolve the issue for you, try running the following command in a terminal:

    snap connect chromium:password-manager-service

> * cross site logins are broken (sign into gmail for work, and other
> sites that use that gmail auth just fail).

Would you mind filing a separate bug for this? This will make it easier to track and investigate the problem.

> * some extensions break (e.g. the JSONViewer is
> silently-non-functional.)

Same as above, would you mind filing a separate bug for this?

Thanks!

Norbert (nrbrtx)
tags: removed: eoan
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.