[snap] chromedriver does not download where configured

[Shaheed Haque]

I've recently been forced to upgrade to the SNAP based chromium setup. After being required to work through reconfiguring my $HOME, learn of the need to set up $XAUTHORITY I just now discovered that none of my Selenium based download tests work because the SNAP setup insists on downloading to:

/home/xxx/snap/chromium/1165/Downloads

rather than where the chromederiver download settings have been configured. Is there a way to override this?

[Shaheed Haque (srhaque-i)]

Oh, in case it was not clear, /home/xxx/snap/chromium/1165/Downloads does not exist, and cannot be created since that's a readonly location. SO Download does not work full stop.

[Olivier Tilloy (osomon)]

I'm not sure I understand the problem. How is ~/snap/chromium/1165/Downloads a read-only location?

Chromium (at least when not run headless) should default to your XDG Downloads directory, what does chrome://settings/downloads show?

Can you share one of your Selenium-based download tests so that I can reproduce and investigate the problem?

[Shaheed Haque (srhaque-i)]

Thanks for the replies.

The main issue for me was that chromedriver - by design as I understand it - does not have Chromium use the normal ~/Downloads folder, but one that has to be configured when initialising chromedriver. I cannot easily share the code, but here is an extract (code like this is widely shared on the web):

self.driver.command_executor._commands["send_command"] = (
  "POST", '/session/$sessionId/chromium/send_command'
)
self.driver.execute("send_command", {
 'cmd': 'Page.setDownloadBehavior', 'params': {'behavior': 'allow', 'downloadPath': /a/place/}}
)

The issue is that the snap setup ignores this location. So tests which are expecting file to end up under "/a/place" don't find them.

Now, while investigating this, I may have mistakenly thought that the lack of the ~/snap/.../Downloads was the problem. Though with hindsight, it might have been because the directory did not exist rather than, as you say, the directory not being writeable if created. At any rate I suspect that, as above, chromedriver will set up Chromium not to use this folder in any event. In other words, this is likely a red-herring.

[Olivier Tilloy (osomon)]

I have managed to reproduce the problem, I'm attaching a test script that attempts to download a file to a location that's not permitted by snapd's strict confinement.

What happens is that the chromium snap is strictly confined, so it can't write files anywhere on the filesystem. In my test I'm setting the downloadPath to $HOME/.local, and the resulting apparmor denial is:

  juin 12 16:35:24 bribon audit[35815]: AVC apparmor="DENIED" operation="mknod" profile="snap.chromium.chromedriver" name="/home/osomon/.local/linux-5.7.2.tar.xz.crdownload" pid=35815 comm="ThreadPoolForeg" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

I'm afraid you will need to update your tests to download files somewhere they can be written (anywhere in your home directory that's not a hidden folder, or under /media or /mnt, for example).

[Vincent NOEL (labestiol)]

I have a similar problem trying to download to /tmp/<temporary directory>.

Snap seems to remap it to /tmp/snap.chromium/tmp/<temporary directory>. Chromedriver is allow to write to it, and the download actually works.
The problem is that /tmp/snap.chromium have 700 as permission, so only root can access the file.