Chown to current user


#1

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.


Call for Testing: Inadyn Dynamic DNS Client
Snapping CUPS Printing Stack: Avahi support, system users/groups
#2

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.

In the meantime applications can either be patched to not perform the chown or use the snapcraft preload part: https://github.com/sergiusens/snapcraft-preload.


Call for Testing: Inadyn Dynamic DNS Client
#3

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?


#4

@daniel does the snapcraft preload part not help, then? why/how?


#5

No, the preload part doesn’t help. I do not know why.


#6

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?


#7

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).


#8

It already does this.


#9

While this doesn’t allow chown-to-self, there is an open PR that changes KILL to EPERM: https://github.com/snapcore/snapd/pull/3998. I tested the snap in
GLib plus GIO fails because of fchown. snapcraft-preload ineffective against this PR and see this:

$ 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'

With the non-KILL denial here:

Mar 06 05:04:33 sec-xenial-amd64 audit[2233]: SECCOMP auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=2233 comm="glib-test" exe="/snap/glib-test/x1/bin/glib-test" sig=0 arch=c000003e syscall=93 compat=0 ip=0x7f4a289ad337 code=0x50000
Mar 06 05:04:33 sec-xenial-amd64 kernel: audit: type=1326 audit(1520334273.629:50): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=2233 comm="glib-test" exe="/snap/glib-test/x1/bin/glib-test" sig=0 arch=c000003e syscall=93 compat=0 ip=0x7f4a289ad337 code=0x50000

(notice code=0x50000. KILL use code=0x0). As such, the above PR will address issues with glib file creation.


Strict mode seccomp policy violations now set errno to EPERM instead of killing the process
GLib plus GIO fails because of fchown. snapcraft-preload ineffective
#10

This is now committed to master and slated for 2.32: Strict mode seccomp policy violations now set errno to EPERM instead of killing the process


#11

yeah


#12