Thanks for your reply, I can see the logic. Still, if the whole world would just do what I want, I would rule that all downloads should go to $HOME/Downloads (if it exists). It took me a whopping 15 seconds to figure out where my files got saved to.
But, if not, it’s a great snap, that works as expected on Ubuntu 17.10 on xorg. Thanks for your hard work!
Downloads do go to $HOME/Downloads. But inside a strictly confined snap, $HOME is defined as ~/snap/$SNAP_NAME/$SNAP_REVISION/.
I agree this might be confusing at first.
Thanks for the feedback!
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).
1 Like
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!
Known issue with snapd rejecting URLs passed to xdg-open without a scheme. I just filed bug #1729777 to keep track of it.
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.
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.
is it possible to run this snap in Ubuntu Core?
maybe using the mir-kiosk setup (or otherwise)
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).
2 Likes
@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.
1 Like
I’ll get this fixed in the policy updates for 2.30.
1 Like
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.
2 Likes
Seems that HTML5 +DRM video playback doesn’t work: Netflix redirects to their help page (https://help.netflix.com/en/node/23742)
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).
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.
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!
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.
1 Like