Multiple snaps are failing to run when packaged with strict confinement due to fchown being a blocked syscall. Can we please get a fix for this syscall to allow “chown to myself” into snapd? This will, for example allow things like glib file creation to work out-of-the-box where gimp-2.9.6 as an example currently cannot start because it gets killed when calling fchown on a file it creates to ensure it’s owned by the user who created it. We should also convert the denial to a “permission denied” rather than a signal 31 which completely kills the process.
I get that it seems silly to fchown a file to your userid when you’ve only just created it while running as that userid, because it surely already is owned by your user via the creation process. This seems to be a common pattern in various libraries, however, so we need to allow it to work unmodified.
As mentioned elsewhere, this will be fixed as part of the work for Multiple users and groups in snaps. This work is on the roadmap but not prioritized. To help out, I’m working on this in the background so while it is progressing, it is progressing slowly. Note that chown to root:root is currently allowed.
I’ve encountered an inbuilt functionality in GLib that does a chown-to-self by design (GLib plus GIO fails because of fchown. snapcraft-preload ineffective). It is preventing us from updating GIMP beyond the current release. There is also very similar functionality in irccloud-desktop which is preventing us from updating beyond 0.3 of that project (two stable releases have occurred since, which we haven’t been able to release).
Is there a way we can get chown-to-self expedited separately, because this is affecting multiple snaps now, and appears to be by design in these snaps?
It could be done, but is not trivial because of how chown (and friends), libseccomp and snap-confine all work (it seems like it would be trivial, but alas, https://github.com/seccomp/libseccomp/issues/69). We’ll get to it, but it is a sizable amount of work that is behind some other things.
Much better for the short term would be to fix snapcraft preload. @sergiusens, can you comment?
While it might be beneficial for folks already using this snapcraft-preload part it is hard to discover during runtime (maybe snappy-debug can hint to it too?).
If someone has code already for this, feel free to create a PR and we will give it a review.
For developers not using snapcraft-preload I would encourage just fixing the source. If this is part of something not built, such as an artifact brought in by means of a stage-packages entry I would say we should SRU a fix to 16.04 LTS (implies also solving it for 18.04 LTS).
$ glib-test # first try, no denials
Writing '/home/jamie/snap/glib-test/x1/test-glib-file'
successfully opened '/home/jamie/snap/glib-test/x1/test-glib-file'
$ glib-test # second try, does chown and has EPERM denial
Writing '/home/jamie/snap/glib-test/x1/test-glib-file'
successfully opened '/home/jamie/snap/glib-test/x1/test-glib-file'
