gpsfake fails to run

Status changed to 'Confirmed' because the bug affects multiple users.

I'm using Debian Unstable, but I assume it's the same issue.

Checking the system logs (e.g. via dmesg) reveals entries along the lines of:

audit: type=1400 audit(1606596824.706:63): apparmor="DENIED" operation="mknod" profile="/usr/sbin/gpsd" name="/tmp/gpsfake-5064.sock" pid=5065 comm="gpsd" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

Setting AppArmor for /usr/sbin/gpsd from enforce to complain mode gets gpsfake working again.
(as root):
aa-complain /usr/sbin/gpsd

HTH

NB1 To restore enforced mode (as root):
aa-enforce /usr/sbin/gpsd

NB I think the profile used is in /etc/apparmor.d/usr.sbin.gpsd (which is owned by the gpsd package).
But I don't know what should go in there.

Hello and thanks for this bug report. I can confirm the issue affects both Ubuntu and Debian. Given that the bug doesn't interfere with the most common use cases of gpsd, and that gpsd is currently a sync from Debian, I believe this bug would be best fixed in Debian. Ubuntu will then pick up the fix with the next package sync. This will benefit both the distros, minimize the maintenance effort and allow newer versions of gpsd from Debian to land in Ubuntu faster.

I filed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976152

and I'm linking it to this bug report.

The Apparmor profile was written by Ubuntu people, happy to take a patch for Debian.

I fully agree to the case and to Bernds statement :-)

Hi and happy new year everyone btw.

I can recreate the case easily and confirm the confinement issue.
Rules are always only as good as they were used :-)
By extending use cases or by new version changing behavior the rules have to be kept up to date.

And this is one case we forgot but is easy to add.

If anyone can't wait for the update to land you can (always) add local rules to a profile with local overrides (allowing for e.g. custom configs).
In this case the following will get you going without loosing the confinement (which disable/complain mode would).

echo "/tmp/gpsfake-*.sock rw," | sudo tee -a /etc/apparmor.d/local/usr.sbin.gpsd

The rule above got gpsfake going (no more apparmor blocks) in my case.
If you happen to find more by going deeper on that use case let us know.
As long as we have reasonable use cases we can easily add them unless they appear to be very non-secure. And in that case you can still use a custom rule for your config (=still no need to disable the profile)

While adding the rule I found that since Bernd and I added the profile to the package it was also accepted upstream. There were a few follow on fixes that we should integrate as well.
E.g. the gpsfake fix I just wrote is in there already.
We should use that file from upstream and contribute (or patch if needed) to that.

It also seems someone was very frustrated according to the comments in there.
=> https://gitlab.com/gpsd/gpsd/-/commit/45fa9654a0bd8439a4d9a1381167639694ff6d7a
But TBH many many common use cases work fine AFAICS.
I can understand the pain thou if you are not used to it and tried to add some better guidance to the upstream profile.

I've submitted a PR for this at:
https://gitlab.com/paelzer/gpsd/-/merge_requests/new?merge_request%5Bsource_branch%5D=add-hope-for-apparmor

And to use the upstream one in the packaging at:
https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/merge_requests/10

FYI - the fix for this is in hirsute-proposed right now as Bernd has accepted my changes and uploaded them to Debian (we are in sync atm).

This bug was fixed in the package gpsd - 3.22-2

---------------
gpsd (3.22-2) unstable; urgency=medium

  [ Bernd Zeimetz ]
  * [66691096] Update Apparmor profile from upstream git HEAD.
    Thanks to Christian Ehrhardt (Closes: #976152) (LP: #1894330)

  [ Christian Ehrhardt ]
  * [63f0cbf0] symbols: nanowait came back as (int, timespec*)
    Signed-off-by: Christian Ehrhardt <email address hidden>

 -- Bernd Zeimetz <email address hidden> Wed, 13 Jan 2021 19:20:14 +0100