Ubuntu
chromium-browser package

permission denied when opening a mounted folder in save file dialog

Bug #1850088 reported by Michael Tsang
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Chromium Browser
New
Undecided
Unassigned
chromium-browser (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

After upgrading to Ubuntu 19.10, when I tried to open a file into a sshfs-mounted folder inside my home folder, it says permission denied. This didn't happen at Ubuntu 19.04.

Steps to reproduce:
1. Use sshfs to mount a sftp folder on an empty folder inside my home drive (e.g. ~/.server)
2. Create a soft link in the home folder to a folder inside the mounted sftp file system (e.g. ~/server > .server/home/michael )
3. Open chromium
4. Download a file
5. Enter that folder in the file dialog

Expected result:
I can enter the folder

Actual result:
It says permission denied

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
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
CurrentDesktop: KDE
DRM.card1-HDMI-A-1:
 enabled: disabled
 dpms: Off
 status: disconnected
 edid-base64:
 modes:
DRM.card1-VGA-1:
 enabled: enabled
 dpms: On
 status: connected
 edid-base64: AP///////wBBDGbAJEYAAA8WAQNuMx14LspFpFZLnCUSUFS9SwDRwLMAlQCBgJUPAQEBAQEBAjqAGHE4LUBYLEUA/R4RAAAeAAAA/wBVSEIxMjE1MDE3OTU2AAAA/ABQaGlsaXBzIDIzNENMAAAA/QA4TB5TEQAKICAgICAgAHs=
 modes: 1920x1080 1680x1050 1280x1024 1280x1024 1440x900 1440x900 1024x768 1024x768 800x600 800x600 640x480 640x480 640x480 640x480 720x400
Date: Mon Oct 28 10:14:27 2019
DiskUsage:
 Filesystem Type Size Used Avail Use% Mounted on
 /dev/mapper/vg0-root ext4 230G 190G 29G 87% /
 tmpfs tmpfs 7.8G 165M 7.6G 3% /dev/shm
 /dev/mapper/vg0-root ext4 230G 190G 29G 87% /
InstallationDate: Installed on 2016-10-03 (1119 days ago)
InstallationMedia: Kubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
MachineType: ASUS All Series
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-19-generic root=/dev/mapper/vg0-root ro quiet splash resume=/dev/vg0/swap vt.handoff=7
Snap.ChromeDriverVersion: ChromeDriver 78.0.3904.70 (edb9c9f3de0247fd912a77b7f6cae7447f6d3ad5-refs/branch-heads/3904@{#800})
Snap.ChromiumVersion: Chromium 78.0.3904.70 snap
SourcePackage: chromium-browser
UpgradeStatus: Upgraded to eoan on 2019-10-25 (2 days ago)
dmi.bios.date: 08/13/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2105
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: H81M-E
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2105:bd08/13/2014:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnH81M-E:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.family: ASUS MB
dmi.product.name: All Series
dmi.product.sku: All
dmi.product.version: System Version
dmi.sys.vendor: ASUS

Revision history for this message
Michael Tsang (miklcct) wrote :
Revision history for this message
Jalon Funk (francescohickle15) wrote :

Snaps don't have access to dotfiles in your home dir (anything in ~/.xxx).

The solution for you is to use ~/server instead of ~/.server as mount point.

Revision history for this message
Michael Tsang (miklcct) wrote : Re: [Bug 1850088] Re: permission denied when opening a mounted folder in save file dialog

On Tuesday, 29 October 2019 01:23:01 HKT you wrote:
> Snaps don't have access to dotfiles in your home dir (anything in
> ~/.xxx).
>
> The solution for you is to use ~/server instead of ~/.server as mount
> point.

This is clearly a bug, not a feature. I don't know anything about snap, what I
did was to just upgrade my Ubuntu from 19.04 and 19.10 and suddenly even file
saving did not work. I used a hidden folder as a mount point because *I want
it to be hidden*, and I created a non-hidden soft link into somewhere inside:

lrwxrwxrwx 1 michael michael 20 Oct 23 2018 server -> .server/home/
michael

I just opened the soft link "server" as in the past and it suddenly pops out
"permission denied" which I'm sure that I have the appropriate permissions to
the folder involved as I can open the folder in other apps.

Your so-called "solution" is not a solution for me because I don't want to
have another visible folder to make my home folder clumsy. I'm using Google
Chrome (the one provided by Google) as a workaround until a "proper fix"
arrives.

Michael

Revision history for this message
Jalon Funk (francescohickle15) wrote :

The "proper fix" may never arrive because sandboxing is core feature of snaps and blocking access to dotfiles is inherent part of sandbox. So from snap perspective your workflow is invalid.

There are two solutions: adjust your workflow or abandon chromium snap. It's up to you what you choose.

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

Michael, I understand this is a functional regression as far as you're concerned, and it's unfortunate. As Jalon Funk pointed out though, access to dot files and folders inside $HOME is forbidden by snap confinement, and that is indeed considered a feature (enhancing security in the general case).

While acknowledging the problem, I'd be interested in knowing whether changing your mount point from ~/.server to e.g. ~/server works around the problem?

Changed in chromium-browser (Ubuntu):
status: New → Incomplete
Revision history for this message
Phil Merricks (seffyroff) wrote :

Another fairly simple path to hit this issue is when I mount a drive from the File Browser. It gets mounted automatically under /media/$USER/<random ID> and isn't accessible in the Snap by default.

I guess installing the snap with --classic would resolve it?

Revision history for this message
Jalon Funk (francescohickle15) wrote :

It's not possible to install non-classic snap (like chromium) with --classic switch.

You can get access to /media/$USER/<random ID> through removable-media interface which you have to manually connect to chromium snap.

https://snapcraft.io/docs/removable-media-interface

Revision history for this message
david feeney (dpfeeney) wrote :

@osomon regarding your question "... ~/server works around the problem?", I have a tmpfs mount in my $HOME (19.10) and it is inaccessible to chromium.

/etc/fstab
tmpfs /home/david/ramdisk tmpfs rw,size=2048M 0 0

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

@david: this is most likely because your /home/david/ramdisk mount point is owned by root, not by your user. Try "sudo chown david:david /home/david/ramdisk", does it fix the problem?

Revision history for this message
gaara (yoggic) wrote :

I have the same bug -
When I want to open a file in /media/user/folder, Chromium refuses.
"Permission denied"

Revision history for this message
gaara (yoggic) wrote :

Ok, I have found a fix:

snap connect chromium:removable-media

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

Other bug subscribers

Remote bug watches

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