gpsd unable to open chrony PPS socket

[Mark Shuttleworth]

[Impact]

 * Current GPSD apparmor isolation is too strict to use PPS devices
   properly.

 * backport changes we added to 20.10 to fix this

[Test Case]

 * Set up a PPS device with chrony/gpsd as described in [1]
   Check the log output.

   Bad case:
   gpsd:PROG: PPS:/dev/ttyS0 connect chrony socket failed: /var/run/chrony.ttyS0.sock, error: -2, errno: 13/Permission denied

   Good case does not show the errors above. Check that gpsd properly
   initializes the device by ensuring this works for the whole stack
   and chrony ends up getting proper PPS time data (also in [1]).

[1]: https://ubuntu.com/server/docs/network-ntp

[Regression Potential]

 * As always with apparmor changes the regression risk comes in two way:
   - we allow more than before, that could be insecure but we have the +1
     from the security team and optimized to further reduce permissions.
   - we deny some access (to silence warnings) which could, if strictly
     required for un-tested use cases break these use-cases. Neither in the
     tests nor in the review/discussion such cases were identified.

[Other Info]

 * This is accepted in Debians packaging git, if not in Groovy in time I'll
   need to put an 3.20-8ubuntu1 there, but I can preparing the SRU
   independent to that.

---- ----

GPSd fails to access the socket used to communicate PPS signals with Chrony.

From the startup log:

gpsd:PROG: PPS:/dev/ttyS0 connect chrony socket failed: /var/run/chrony.ttyS0.sock, error: -2, errno: 13/Permission denied

The socket in question has these permissions:

$ ls -l /var/run/chrony.ttyS0.sock
srwxr-xr-x 1 root root 0 Apr 10 17:25 /var/run/chrony.ttyS0.sock

gpsd is running as its own user gpsd, and chrony as _chrony.

$ groups gpsd
gpsd : dialout
$ groups _chrony
_chrony : _chrony

I have tried adding gpsd to group _chrony and changing the ownership and permissions of chrony.ttyS0.sock but to no avail. I always see the permission denied message.

AppArmor rules for gpsd appear to allow the connection, too:

  # default paths feeding GPS data into chrony
  /{,var/}run/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,
  /tmp/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,

So I am stumped.

[Christian Ehrhardt  (paelzer)]

For the sake of apparmor rules being sometimes odd, there is no "other" apparmor denial in your dmesg around that time is there?

[Christian Ehrhardt  (paelzer)]

Hmm, I wanted to debug the init_hook function on my system to check the details.
Also my setup won't fail the same way as yours, it just doesn't try to connect - it did in the Bionic past, but that was on a different (now broken) system.

But also:
   gpsd-clients-dbgsym : Depends: gpsd-clients (= 3.20-6) but 3.20-8 is to be installed
   gpsd-dbgsym : Depends: gpsd (= 3.20-6) but 3.20-8 is to be installed

So dbgsym publishes are out of sync again. I'll ping archive people to resolve but it seems debugging has to wait a bit ...

[Christian Ehrhardt  (paelzer)]

From some local debugging, without PPS the code is not trying to reach this path that I'd need to debug, so this is blocked by https://bugs.launchpad.net/ubuntu/+source/gpsd/+bug/1872178/comments/2 as well.

I'll debug this further once I have a a device here.

[Christian Ehrhardt  (paelzer)]

If GPSD tries to contact chrony I see entries like this:
  gpsd[2649]: gpsd:PROG: PPS:/dev/ttyAMA0 chrony socket /var/run/chrony.ttyAMA0.sock doesn't exist
  gpsd[2649]: gpsd:PROG: PPS:/dev/ttyUSB1 chrony socket /var/run/chrony.ttyUSB1.sock doesn't exist

I reduced it to just the device that seems to have working PPS and retried.
With chrony set up to expect /var/run/chrony.ttyUSB0.sock via

in Chrony.conf I set
# get input from GPSD
refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2
refclock SOCK /var/run/chrony.ttyXX.sock refid PPS

After restart of chrony I had
srwxr-xr-x 1 root root 0 Apr 27 14:26 /var/run/chrony.ttyUSB0.sock=

And with that I get:
Apr 27 14:27:53 ubuntu gpsd[2568]: gpsd:PROG: PPS:/dev/ttyUSB0 connect chrony socket failed: /var/run/chrony.ttyUSB0.sock, error: -2, errno: 13/Permission denied

Ok it is reproducible now and thereby debuggable.
Maybe the code that drops GPSD permissions runs to early now or anything like that.
But at least I can now action on it over here.

[Christian Ehrhardt  (paelzer)]

Clearly some apparmor hits are going on even though not too much details can be seen here.
  apparmor="DENIED" operation="ptrace" profile="/usr/sbin/gpsd" pid=2600 comm="gpsd" requested_mask="read" denied_mask="read" peer="unconfined"

Chrony as one potential candidate is confined as well, ...
I'm discussing with the security Team what this might try to reach and how to improve. Might not be the actual root cause here, but worth to track down.

In complain mode they do not bring any other rules:
  apparmor="ALLOWED" operation="ptrace" profile="/usr/sbin/gpsd" pid=2987 comm="gpsd" requested_mask="read" denied_mask="read" peer="unconfined"

But it makes it work.
Not only does it get the socket connect to chrony (this bug) but also the intialization of PPS seems apparmor related. Here GPSD init logs with default and complain apparmor.

==> gpsd.aa.log <==
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)
gpsd:PROG: PPS:/dev/ttyUSB0 connect chrony socket failed: /var/run/chrony.ttyUSB0.sock, error: -2, errno: 13/Permission denied
gpsd:INFO: KPPS:/dev/ttyUSB0 device not found.
gpsd:WARN: KPPS:/dev/ttyUSB0 kernel PPS unavailable, PPS accuracy will suffer
gpsd:PROG: PPS:/dev/ttyUSB0 thread launched
gpsd:INFO: PPS:/dev/ttyUSB0 ntpshm_link_activate: 1
gpsd:INFO: device /dev/ttyUSB0 activated
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 112

==> gpsd.noaa.log <==
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)
gpsd:INFO: KPPS:/dev/ttyUSB0 RFC2783 path:/dev/pps1, fd is 9
gpsd:INFO: KPPS:/dev/ttyUSB0 pps_caps 0x1133
gpsd:INFO: KPPS:/dev/ttyUSB0 have PPS_CANWAIT
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS will be used
gpsd:INFO: PPS:/dev/ttyUSB0 ntpshm_link_activate: 1
gpsd:INFO: device /dev/ttyUSB0 activated
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 112
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: startup at 2020-04-27T14:43:19.000Z (1587998599)
gpsd:INFO: /dev/ttyUSB0 identified as type u-blox, 1 sec @ 9600bps
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: PPS:/dev/ttyUSB0 Clear hooks called clock: 1587998611.999974735 real: 1587998611.000000000: accepted

I need to talk with the security Team even more.
Maybe the pps access ioctl or such is misdetected as ptrace?
And from there things go south ...?

[John Johansen (jjohansen)]

unfortunately the kernel actually uses ptrace_access_check for more than just ptrace, and the LSM (and hence apparmor) is not given context as to where the check is coming from. The current full list that can trigger an apparmor ptrace check is below. We can discard any that are not using a variant of MODE_READ*

the mostly likely candidate is reading proc files, but this is going to take some more sleuthing to trace the source operation. AppArmor will throw an EACCES so if we can setup a trace to catch that, it would be helpful in tacking this down.

$ git grep security_ptrace_access_check
include/linux/security.h:int security_ptrace_access_check(struct task_struct *child, unsigned int mode);
include/linux/security.h:static inline int security_ptrace_access_check(struct task_struct *child,
kernel/ptrace.c: return security_ptrace_access_check(task, mode);
security/security.c:int security_ptrace_access_check(struct task_struct *child, unsigned int mode)
jj@flux:~/linux-kernels/linux-2.6$ emacs kernel/ptrace.c &
[4] 9110
jj@flux:~/linux-kernels/linux-2.6$ git grep ptrace_may_access
Documentation/process/adding-syscalls.rst:``ptrace_may_access()``) so that only a calling process with the same
Documentation/translations/it_IT/process/adding-syscalls.rst:la chiamata ``ptrace_may_access()``) di modo che solo un processo chiamante
fs/proc/array.c: permitted = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS | PTRACE_MODE_NOAUDIT);
fs/proc/base.c: if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
fs/proc/base.c: if (!ptrace_may_access(task, PTRACE_MODE_ATTACH_FSCREDS)) {
fs/proc/base.c: allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
fs/proc/base.c: return ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
fs/proc/base.c: if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
fs/proc/base.c: if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
fs/proc/base.c: if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)) {
fs/proc/namespaces.c: if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)) {
fs/proc/namespaces.c: if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)) {
include/linux/ptrace.h: * ptrace_may_access - check whether the caller is permitted to access
include/linux/ptrace.h:extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
include/linux/sched/mm.h: * and ptrace_may_access with the mode parameter passed to it
kernel/cred.c: * the credential change; otherwise, a __ptrace_may_access()
kernel/cred.c: * Pairs with a read barrier in __ptrace_may_access().
kernel/events/core.c: if (!ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS))
kernel/fork.c: !ptrace_may_access(task, mode)) {
kernel/futex.c: if (!ptrace_may_access(p, PTRACE_MODE_READ_REALCREDS))
kernel/futex.c: if (!ptrace_may_access(p, PTRACE_MODE_READ_REALCREDS))
kernel/kcmp.c: if (!ptrace_may_access(task1, PTRACE_MODE_READ_REALCREDS) ||
kernel/kcmp.c: !ptrace_may_access(task2, PTRACE_MODE_READ_REALCREDS)) {
kernel/ptrace.c:static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
kernel/ptrace.c:bool ptrace_may_access(struct task_struct *task...

[Christian Ehrhardt  (paelzer)]

After a discussion with jjohansen (thanks!) I learned that some of the procfs access will trigger ptrace rules. Odd, but nice to know ...

After that was clear I was fixing he initial fail. I found a bunch of further issues hidden behind those but it seems at least in my local setup the following makes everything work.

1. We need to track disconnected
/usr/sbin/gpsd flags=(attach_disconnected) {

2. And we need those for PPS:
 # required for pps initialization
 capability dac_read_search,
 capability sys_ptrace,
 capability sys_time,
 /sys/devices/virtual/pps/ r,
 # triggerd on some /proc access needed for pps
 ptrace read peer=unconfined,
 # to submit data to chrony
 ptrace read peer=/usr/sbin/chronyd,
 # for lubusb
 /sys/devices/**/usb[0-9]*/** r,

I'll ask the security team to +1 on those and will try with another device on Wednesday (waiting for an antenna cable adapter)

[Christian Ehrhardt  (paelzer)]

@Mark, I know it is unlikely you find the time for it this week.
But if you can - modifying the files in /etc/apparmor.d and retrying might help to test this on more devices.

[John Johansen (jjohansen)]

@paelzer per the proposed fix in #7 you can stick my sign-off on it.

Signed-off-by: John Johansen <email address hidden>

[Christian Ehrhardt  (paelzer)]

I was tracing caps and syscalls for the security Team.

$ while ! pidof gpsd; do sleep 0.001; done; sudo capable-bpfcc -K -p $(pidof gpsd)
...
Does not report anything.

The same without -p and runnign through gpsd init is better.
CAP_DAC_READ_SEARCH is from some /proc access and the ptrace seems to be related to the same.

I also gathered strace data for a gpsd init.

[Christian Ehrhardt  (paelzer)]

The only "bad rule" is for ptrace/unconfined but I'm not sure what to do about it.

This is the backtrace that will trigger all ptrace/read calls.
"just" an open to /dev/ttyUSB0 with mode=2 and flags => (mode | O_NONBLOCK | O_NOCTTY).

#0 __libc_open64 (file=0xaaaab026c300 <devices+6080> "/dev/ttyUSB0", oflag=2306)
    at ../sysdeps/unix/sysv/linux/open64.c:37
#1 0x0000aaaab01f87b8 in open (__oflag=2306,
    __path=0xaaaab026c300 <devices+6080> "/dev/ttyUSB0")
    at /usr/include/aarch64-linux-gnu/bits/fcntl2.h:57
#2 gpsd_serial_open (session=0xaaaab026ab40 <devices>) at serial.c:528
#3 0x0000aaaab01ed934 in gpsd_open (session=0xaaaab026ab40 <devices>) at libgpsd_core.c:558
#4 0x0000aaaab01ede54 in gpsd_activate (session=0xaaaab026ab40 <devices>, mode=2)
    at libgpsd_core.c:567
#5 0x0000aaaab01d32cc in open_device (device=0xaaaab026ab40 <devices>) at gpsd.c:686
#6 0x0000aaaab01d4798 in gpsd_add_device (flag_nowait=<optimized out>,
    device_name=<optimized out>) at gpsd.c:746
#7 gpsd_add_device (device_name=0xffffeadb485b "/dev/ttyUSB0", flag_nowait=<optimized out>)
    at gpsd.c:715
#8 0x0000aaaab01cf664 in main (argc=6, argv=0xffffeadb4408) at gpsd.c:2139

So on this kind of device it seems glibc/kernel throw that in.

I discussed with #security and it seems there is no great way out that seems worth the effort - gladly the rest of the profile keeps it a bit in line and it is only a read rule.

The odd thing there is that the open call seems to call back to fusercount.
Due to -O2 this is a bit unprecise and inlined but it seems that is is.

I need to teach it to recognize an "apparmor can't access" from a real fail.
Then I could keep it forbidden (and therefore safer) but have the init work.

[Christian Ehrhardt  (paelzer)]

Essentially the check iterates over all /proc/<numeric>
And there it does readlink to check if any has the target open.
In my example if any FD is a link to /dev/ttyUSB0

But this already is "graceful" the apparmor deny to
  readlink(fdpath, linkpath, sizeof(linkpath)
is
  apparmor="DENIED" operation="ptrace" profile="/usr/sbin/gpsd" pid=29314 comm="gpsd" requested_mask="read" denied_mask="read" peer="unconfined"
for path
  /proc/1/fd/2

The retval then is -1 and and that makes it continue, which would not increase "cnt" of the pids that have it opened. So keeping that blocked should not break function at all.

And usually this has in dmesg something like
[52111.940870] kauditd_printk_skb: 153 callbacks suppressed

I checked and we can functionally go on with
 # triggered on fusercount, not strictly required and unsafe to allow
 # adding a denial rule silences the warnings
 deny ptrace read peer=unconfined,

[Christian Ehrhardt  (paelzer)]

The next critical one was cap "sys_ptrace", that comes from another part of the code but also isn't strictly required for functionality. Let us understand why that is triggered.

That one seems to be even more interesting.
It does trigger under gdb, but not when single stepped to find where it originates ... ?!

[Christian Ehrhardt  (paelzer)]

Ok, it seems after eliminating the above issue the sys_ptrace isn't triggered anymore.
And even if it is it seems not required for the functionality and would be rather unsafe.

Until I get a GPS lock chrony sees:
chronyc> sources
210 Number of sources = 10
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? GPS 0 4 3 14 +1115ms[+1115ms] +/- 200ms
#? PPS 0 4 1 14 +2000ms[+2000ms] +/- 69us
^- chilipepper.canonical.com 2 6 17 28 -611us[ -611us] +/- 44ms
...

After a while (and depending on signal quality) it syncs to the PPS.

chronyc> sources
210 Number of sources = 10
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#x GPS 0 4 177 24 -876ms[ -876ms] +/- 200ms
#- PPS 0 4 177 21 +916us[ +916us] +/- 63us
^- chilipepper.canonical.com 2 6 37 53 +33us[ +33us] +/- 33ms
^- golem.canonical.com 2 6 37 52 +448us[ +448us] +/- 43ms
^- alphyn.canonical.com 2 6 73 50 +552us[ +552us] +/- 110ms
^- pugot.canonical.com 2 6 37 52 -429us[ -429us] +/- 50ms
^- a08.alphasrv.net 2 6 37 53 +1943us[+1943us] +/- 52ms
^- dns02.xstream-labs.com 2 6 37 53 +568us[ +568us] +/- 36ms
^- stratum2-3.NTP.TechFak.U> 2 6 37 53 -861us[ -861us] +/- 14ms
^* mail.masters-of-cloud.de 3 6 37 54 -45us[ -593us] +/- 12ms

Note sometimes it considers the GPS/PPS too noisy, but that might be right as I don't have the most pricey receiver nor the best reception. Or it considers (after a while) the PPS as good, but had already settles on a server and is not combining PPS with it despite the order of magnitude better resolution)
More antennas arriving later this week ...

[Christian Ehrhardt  (paelzer)]

Overall rules to go with seems to be

 # required for pps initialization
 capability dac_read_search,
 capability sys_time,
 /sys/devices/virtual/pps/ r,
 # to submit data to chrony
 ptrace read peer=/usr/sbin/chronyd,
 # for libusb
 /sys/devices/**/usb[0-9]*/** r,
 # triggered on fusercount, not strictly required and unsafe to allow
 # adding a denial rule silences the warnings
 deny ptrace read peer=unconfined,

[Christian Ehrhardt  (paelzer)]

Note, give it time and it will be happy with PPS at better accuracy.

chronyc> sources
210 Number of sources = 10
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#x GPS 0 4 377 21 -879ms[ -879ms] +/- 200ms
#* PPS 0 4 377 22 -71us[ -111us] +/- 61us
^- chilipepper.canonical.com 2 6 377 33 -284us[ -322us] +/- 37ms
^- golem.canonical.com 2 6 377 31 -845us[ -883us] +/- 45ms
^- alphyn.canonical.com 2 6 337 30 -28us[ -66us] +/- 88ms
^- pugot.canonical.com 2 6 377 32 -432us[ -470us] +/- 51ms
^- a08.alphasrv.net 2 6 377 33 +229us[ +191us] +/- 54ms
^- dns02.xstream-labs.com 2 6 377 33 -724us[ -762us] +/- 38ms
^- stratum2-3.NTP.TechFak.U> 2 6 377 32 -1166us[-1204us] +/- 13ms
^- mail.masters-of-cloud.de 3 6 377 34 -2426us[-2464us] +/- 13ms

Trying multi-gps later this week.

[Christian Ehrhardt  (paelzer)]

Further tests completed, all good with the new rules.

Waiting for salsa to be back up to propose the apparmor changes to Bernd.

[Jamie Strandboge (jdstrand)]

> # required for pps initialization
> capability dac_read_search,
> capability sys_time,
> /sys/devices/virtual/pps/ r,
> # to submit data to chrony
> ptrace read peer=/usr/sbin/chronyd,
> # for libusb
> /sys/devices/**/usb[0-9]*/** r,
> # triggered on fusercount, not strictly required and unsafe to allow
> # adding a denial rule silences the warnings
> deny ptrace read peer=unconfined,

I believe you said that dac_read_search was due to the /proc accesses that also trigger the ptrace rule. Perhaps it can also be suppressed?

Either way, thanks for all the investigation! +1 for the rules as is. If you aren't blocking dac_read_search, can you add what in the pps initialization needs it? Eg:

# required for pps initialization (foo() from bar.c traverses /proc)

or something?

[Christian Ehrhardt  (paelzer)]

In the meantime I also was able to track down that sys_ptrace was for fusercount.
So no adding that was ok, since it triggers only a few times (even seems to be only once per reboot) I'm not sure about adding a denial - it is not as log-filling as the other case was.

I further debugged for the dac_read_search as jdstrand asked for.
Yes it also is from the fusercnt search and can be dropped.

I tried various setups and got cases with up to 3xdac_read_search and 3xsys_ptrace.
Sometimes it also triggers dac_override.
All of that belongs to fusercount and can be blocked without a functional drawback.

I further found that it will hit two more cap checks on a clean setup after reboot:

apparmor="DENIED" operation="capable" profile="/usr/sbin/gpsd" pid=8783 comm="gpsd" capability=16 capname="sys_module"

Those two is when gpsd starts and `pps_ldisc` isn't loaded yet.
Interestingly enough it is able to load it despite the denials.
That is because the kernel implicitly loads it on pps creation.
So we can deny the general capability to load/unload modules for gpsd process and not loose functionality nor get the log filled every time.

Ok so as final result we have the following rules which will have no log filling denials and allow to work with PPS devices just nicely (until we find a very special other device that behaves differently).

1. flags
/usr/sbin/gpsd flags=(attach_disconnected) {

2. rules
 # required for pps initialization
 capability sys_time,
 /sys/devices/virtual/pps/ r,

 # to submit data to chrony
 ptrace read peer=/usr/sbin/chronyd,

 # for libusb
 /sys/devices/**/usb[0-9]*/** r,

 # triggered on fusercount, not strictly required and unsafe to allow
 # adding a denial rule silences the warnings
 deny ptrace read peer=unconfined,
 deny capability sys_ptrace,
 deny capability dac_read_search,
 deny capability dac_override,

 # gpsd tries to load pps_ldisc directly, but gpsd doesn't need
 # the general power of sys_module, pps_ldisc is auto-loaded
 # by the kernel when gpsd is creating the pps device
 deny capability sys_module,

[Christian Ehrhardt  (paelzer)]

FYI - fix submitted as part of PR https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/merge_requests/5

[Jamie Strandboge (jdstrand)]

Looks great. As an aside, this is exactly why we investigate where the accesses are coming from. If we didn't, gpsd would've been allowed to read potentially sensitive data of other processes and load kernel modules (yikes!).

Thank you for sticking with it :)

[Launchpad Janitor (janitor)]

This bug was fixed in the package gpsd - 3.20-11

---------------
gpsd (3.20-11) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [232c8d73] d/rules: fix ubxtool to use python3 in the gpsd package (LP: #1878158)
    Signed-off-by: Christian Ehrhardt <email address hidden>

 -- Bernd Zeimetz <email address hidden> Tue, 12 May 2020 13:49:15 +0200

[Christian Ehrhardt  (paelzer)]

The auto-sync in groovy also included 3.20-8/3.20-9 which covers this issue here:

gpsd (3.20-10) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [7670b61e] exchange gpsd-client/tools content
  * [fb81a96a] examples also need to be in -clients instead of -tools then
  * [7f8d06a8] d/control[.in]: moving gpsctl still breaks gpsd-clients
    (<< 3.20-9) for upgraders never seeing the version in experimental

  [ Bernd Zeimetz ]
  * [b448fb08] Merge branch 'exchange-clients-and-tools' into 'master'
    exchange gpsd-client/tools content
    See merge request debian-gps-team/pkg-gpsd!6

 -- Bernd Zeimetz <email address hidden> Mon, 11 May 2020 14:40:08 +0200

gpsd (3.20-9) experimental; urgency=medium

  [ Christian Ehrhardt ]
  * [6a21e6bd] d/usr.sbin.gpsd: improve apparmor rules for PPS
               usage (LP: #1872175 LP: #1872178)
  * [c8b703b4] d/gpsd.default: add USBAUTO option (LP: #1873415)
  * [2fcf9754] split more uncommon tools to gpsd-tools (LP: #1872189)
  * [4a1454fb] d/control[.in]: have gpsd-tools depend on gpsd-clients
               as it extends on cgps
  * Move tools for local HW config into gpsd itself
    - [016cff82] move gpsctl to package gpsd
    - [b78132aa] d/control[.in]: move ubxtool and ntpshmmon to gpsd
  * python fixups for Lintian warnings
    - d/control[.in]: add python3 dependency to gpsd-dbg
    - d/rules: fix the py2/3 fixup applied post build
    - d/rules: let package gpsd be processed by dh_python3
    - d/control[.in]: gpsd needs python as depends

Therefore this is ready for an SRU to focal now

[Christian Ehrhardt  (paelzer)]

Waiting in Focal-unapproved since yesterday - FYI autopkgtest sniff tests are good as well in https://bileto.ubuntu.com/excuses/4047/focal.html

[Robie Basak (racb)]

Hello Mark, or anyone else affected,

Accepted gpsd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gpsd/3.20-8ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Christian Ehrhardt  (paelzer)]

FYI - I'll verify this tomorrow morning once I've freed up another system.
For the sake of completeness I want to check this on another arch than where I wrote the fixes. TO ensure this really helps in a generic way.

[Christian Ehrhardt  (paelzer)]

As expected before the fix I wasn't able to use any PPS.

Upgrading to gpsd 3.20-8ubuntu0.1 worked without any further breakage.

We see on upgrade that the apparmor profile is replaced:
[12408.110277] audit: type=1400 audit(1589444818.093:34): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/gpsd" pid=7561 comm="apparmor_parser"

Without the fix (prior to the upgrade) we see apparmor denies on e.g. libusb access and such.

Along the way I found some shortcomings in our gpsd/pps doc and fixed it in the serverguide (bug 1878573).

Eventually I can confirm that with 3.20-8ubuntu0.1 I can now use pps on 20.04 properly.
  #* PPS 0 4 37 11 +257us[ +159us] +/- 53us

[Launchpad Janitor (janitor)]

This bug was fixed in the package gpsd - 3.20-8ubuntu0.1

---------------
gpsd (3.20-8ubuntu0.1) focal; urgency=medium

  * d/usr.sbin.gpsd: improve apparmor rules for PPS usage
    (LP: #1872175 LP: #1872178)

 -- Christian Ehrhardt <email address hidden> Thu, 30 Apr 2020 12:40:23 +0200

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for gpsd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.