Call for testing: chromium 62.0.3202.62

[jdstrand]

FYI, @kenvandine is working on a patch to the desktop part that will symlink ~/snap/$SNAP_NAME/$SNAP_REVISION/Downloads to ~/Downloads (along with the other xdg user dirs).

[bashfulrobot]

The only issue I have run into so far is when downloading a file, the “open folder” option does not work. I do have snapd-xdg-open installed. I also tried changing the download location over to the traditional downloads folder. No, go.

However, all my extensions seem to be tip top!

[oSoMoN]

the “open folder” option does not work

Known issue with snapd rejecting URLs passed to xdg-open without a scheme. I just filed bug #1729777 to keep track of it.

[mvo]

I am able to reproduce the nvidia failure on Ubuntu 17.10. I suspect hitting the issue depends on the nvidia driver version. I use nvidia-384.

After a bit of debugging it turns out that one of the helper processes of chromium runs: mknod("/dev/nvidiactl", S_IFCHR|0666, makedev(195, 255)) which is not allowed. Its unclear why it is trying to mknod this device because it is already available in the namespace that chromium runs in.

[mvo]

With a bit more data from strace I get the following picture:

...
[pid  6555] stat("/dev/nvidiactl", {st_dev=makedev(0, 6), st_ino=487, st_mode=S_IFCHR|0666, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(195, 255), st_atime=2017-11-03T12:14:40+0100.694587974, st_mtime=2017-11-03T12:14:40+0100.694587974, st_ctime=2017-11-03T12:14:40+0100.694587974}) = 0
[pid  6555] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=ENOENT, si_call_addr=0x7fc59eaf002d, si_syscall=__NR_open, si_arch=AUDIT_ARCH_X86_64} ---
[pid  6555] stat("/dev/nvidiactl", 0x7ffc10066500) = -1 EPERM (Operation not permitted)
[pid  6555] mknod("/dev/nvidiactl", S_IFCHR|0666, makedev(195, 255)) = ?

What is odd is that the stat("/dev/nvidiactl") works and then stops working.

[Hilikus]

is it possible to run this snap in Ubuntu Core?
maybe using the mir-kiosk setup (or otherwise)

[oSoMoN]

Those should be harmless, it’s chromium trying to create a shortcut (presumably to itself) in the applications menu (see https://cs.chromium.org/chromium/src/chrome/browser/shell_integration_linux.cc).

Corresponding bug report.

[jdstrand]

After a bit of debugging it turns out that one of the helper processes of chromium runs: mknod("/dev/nvidiactl", S_IFCHR|0666, makedev(195, 255)) which is not allowed. Its unclear why it is trying to mknod this device because it is already available in the namespace that chromium runs in.

With the help of @popey and @oSoMoN, we found that adding mknod to the seccomp policy allows things to work. We then looked at an strace of chromium with the policy change and discovered that chromium is unconditionally and AFAICT needlessly doing mknod()s, getting EPERMs and then doing an open(), which succeeds. Because the default snapd policy disallows mknod, this process is killed in strict mode, thus resulting in the black screen. This is a chromium bug; chromium should not be calling mknod() on an existing file which wouldn’t succeed anyway.

Now, if snapd’s seccomp sandbox sent EPERM instead of kill (see the upcoming https://github.com/snapcore/snapd/pull/3998), then that chromium process wouldn’t be killed and things should just work. Using mknod on character and block devices requires CAP_MKNOD to be able to successfully create devices and apparmor mediates this capability. As a result, we can add a workaround rule to the browser-support policy by adding mknod - |S_IFCHR but with a corresponding audit deny capability mknod, apparmor rule which will make it so that the chromium process won’t be killed on mknod, but it still won’t be able to create character devices. When we set the seccomp policy to EPERM instead of kill, this workaround policy can be removed.

@popey, can you report back with the test instructions I gave on IRC (ping me on IRC if you have trouble).

[popey]

@jdstrand the change you posted to me on irc worked. I was able to launch the chromium snap on my nVidia based laptop with your mods.

[jdstrand]

I’ll get this fixed in the policy updates for 2.30.

[jdstrand]

https://github.com/snapcore/snapd/pull/4359 has the workaround rules.

[daniel]

U2F (Universal 2nd Factor) isn’t working when signing into my gmail account trying to use my yubikey. This is a USB device which IIRC chromium needs bidirectional communication with.

[daniel]

Seems that HTML5 +DRM video playback doesn’t work: Netflix redirects to their help page (https://help.netflix.com/en/node/23742)

[oSoMoN]

DRM video playback was broken in the chromium ubuntu package (deb) until version 63 that has been published earlier this week (see bug #1652110). Even with that fixed version, you still need two things to make this work:

• have google-chrome installed (it provides the actual content decryption module, called widevine, which we cannot ship for legal reasons)
• override the user agent string to pretend to be chrome (netflix does user agent sniffing)

This won’t work with a snap, because for the same legal reasons it cannot ship the CDM library, and it will not be able to see it if it’s installed on the system because of strict confinement (unless we punch a hole in the security profile to allow access to /opt/google/chrome/libwidevinecdm.so).

[jdstrand]

This won’t work with a snap, because for the same legal reasons it cannot ship the CDM library, and it will not be able to see it if it’s installed on the system because of strict confinement (unless we punch a hole in the security profile to allow access to /opt/google/chrome/libwidevinecdm.so).

That wouldn’t work anyway, since the snap’s runtime environment won’t use /opt from the host. What could work is if you were able to trick chromium to look for it somewhere within the snap’s area, then have instructions for the user copy the file to this area.

[oSoMoN]

What could work is if you were able to trick chromium to look for it somewhere within the snap’s area

Thanks for the suggestion! This is now being tracked by bug #1738149.

[oSoMoN]

U2F (Universal 2nd Factor) isn’t working when signing into my gmail account trying to use my yubikey.

I have an old yubikey from 2012 that doesn’t support U2F, unfortunately, so I can’t test this myself.

I have filed bug #1738164 to track the issue, could you please look into apparmor/seccomp denials and attach your findings to the bug report? Thanks!

[oSoMoN]

Thanks @jdstrand. I’ve just had access to a laptop with a nvidia GPU running the proprietary driver, and I can confirm that the chromium snap works with snapd 2.30 from the candidate channel.

[Wimpress]

Work on 18.04 daily with nvidia proprietary drivers, using:

snap    2.30+git476.f91a849~ubuntu16.04.1
snapd   2.30+git476.f91a849~ubuntu16.04.1
series  16
ubuntu  18.04
kernel  4.13.0-17-generic

[Syntist]

Snap is working on Arch Linux,

Snap version:

[syntist@Syntist-PC ~]$ snap version
snap      2.30.r285.g7855e9512-1
snapd     2.30.r285.g7855e9512-1
series    16
antergos  
kernel    4.14.8-1-ARCH

[syntist@Syntist-PC ~]$ snap list
Name      Version       Rev   Developer  Notes
chromium  62.0.3202.94  128   canonical  -
core      16-2.30       3748  canonical  core

Nvidia Driver:

[syntist@Syntist-PC ~]$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  387.34  Tue Nov 21 03:09:00 PST 2017
GCC version:  gcc version 7.2.1 20171128 (GCC) 

But no H/W Acceleration.