This bug was fixed in the package gpsd - 3.20-6
---
gpsd (3.20-6) unstable; urgency=medium
[ Bernd Zeimetz ]
* [b0d9ef06] Fix autopkgtest for new systemd releases.
Thanks to Michael Biebl (Closes: #953760)
[ Christian Ehrhardt ]
* [4c4e5ea1] device-hook apparmor fixes (LP
The former Delta:
4 * [b0d9ef06] Fix autopkgtest for new systemd releases.
5 Thanks to Michael Biebl (Closes: #953760)
As well as my new suggested fix
8 * [4c4e5ea1] device-hook apparmor fixes (LP: #1868363)
9 The manpage
As we can't sync from Debian anyway (right now due to the feature freeze) here
also an Ubuntu MP to fix it in Focal.
=>
https://code.launchpad.net/~paelzer/ubuntu/+source/gpsd/+git/gpsd/+merge/381292
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/gpsd/+git/gpsd/+merge/381292
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868363
Title:
/etc/gpsd/device-hook not a
@David - could I ask you a favor. With the new package that now is able to call
the device-hook - could you make your device-hook (for a test) just do `echo
"ok"`?
I want to check if the ptrace denials are dependent to the content that you had
in that hook.
--
You received this bug notificatio
Submitted for review and also Debian inclusion. That will make sure it
works there as well, we don't derive too much from each other and we
will later be able to re-sync gpsd in 20.10.
=> https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/merge_requests/4
--
You received this bug notification b
Thanks for the check David.
It intentionally runs under the same confinement as gpsd does to not break out
too easily.
You can modify you local allowance in:
/etc/apparmor.d/local/usr.sbin.gpsd
That file is intended to take whatever you want to custom-change in the
apparmor rules for gpsd.
It
The script now gets executed but doesn't have the original permissions,
so I need to rework what it does. Here is what I get on the console:
dak@lola:/usr/local/tmp/lilypond$ sudo gpsd -n -N /dev/ttyACM2
/etc/gpsd/device-hook: 2: cannot create /tmp/bubu: Permission denied
/etc/gpsd/device-hook:
@David - does it work with the new build or are there any ptrace issues
left?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868363
Title:
/etc/gpsd/device-hook not actually called
To manage notifi
On Wed, Mar 25, 2020 at 02:54:24PM -, David Kastrup wrote:
> I don't even think it directly calls the interpreter: I discovered that my
> hashbang was
> #!/bin/bash
> while the complained was about /usr/bin/dash (and still is).
This may be due to a confusing, relatively new, symlink:
$ ls -l
3.20-5ubuntu2~ppa3I just uploaded 3.20-5ubuntu2~ppa3 which also has the
rule for dash as found in many other packages.
@David
Can you retry with that version once built and report the remaining denials (if
any)?
--
You received this bug notification because you are a member of Ubuntu
Bugs, whic
Audit mentions /bin/dash, not /usr/bin/dash . Sorry.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868363
Title:
/etc/gpsd/device-hook not actually called
To manage notifications about this bug g
The new upload 3.20-5ubuntu2~ppa2 will have the latter rule as well.
But I can't get it to fake a device in my virtual env to trigger the issue you
are seeing.
Therefore I'm waiting on a new report by David how far he gets now.
--
You received this bug notification because you are a member of Ub
gpsd.h:1062:#define DEVICEHOOKPATH "/" SYSCONFDIR "/gpsd/device-hook"
The dash call also isn't uncommon, if still failing lets add it:
https://codesearch.debian.net/search?q=+%2Fbin%2Fdash.*%2C&literal=0
Would be this then:
/bin/dash rix,
@David
If you fail on dash still, you can add the line
Version 3.20-5ubuntu2-ppa1 is what I have installed.
I don't even think it directly calls the interpreter: I discovered that my
hashbang was
#!/bin/bash
while the complained was about /usr/bin/dash (and still is).
That rather sounds like system rather than exec is being used here. Or
the system
As so many other packages recently we will also in some environments
(e.g. containers) need the allowance to map and execute the own binary.
# own binary
/usr/sbin/gpsd rmix,
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
Hmm, it directly seems to call the interpreter - eager to see if the
rule I added actually helps.
I have not yet added anything for the ptrace denials, it might (hopefully) go
away once the running of the hook inherits the profile as intended.
Otherwise granting ptrace to everything unconfined wo
I beg your pardon, my former build was on an outdated base, due to that
the PPA has a lower version than what we have in Focal.
I rebased and uploaded a new build - New version is 3.20-5ubuntu2~ppa1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
PPA doesn't help.
[113847.653970] audit: type=1400 audit(1585146074.312:1469): apparmor="DENIED"
operation="exec" profile="/usr/sbin/gpsd" name="/bin/dash" pid=363200
comm="gpsd" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
[113847.655351] audit: type=1400 audit(1585146074.313:1470): apparm
The dmesg output looks like the following:
[112720.972130] audit: type=1400 audit(1585144947.600:71): apparmor="DENIED"
operation="exec" profile="/usr/sbin/gpsd" name="/bin/dash" pid=353559
comm="gpsd" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
[112720.973971] audit: type=1400 audit(15851
Without the denial, I'm not entirely sure on rmix, rix, ix.
Lets grant the lowest amount of permissions on the first try.
@David could you try the build in [1] if that resolves your issue?
[1]: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1868363-gpsd-
apparmor-device-hook
--
You received
I totally agree, on apparmor based reports having the dmesg output of
the denial always helps.
I'll try to prep something without that, but if you'd have that at hand
please share it here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
There are several examples of AppArmor profiles allowing execution of
scripts in /etc:
https://codesearch.debian.net/search?q=%28%3Fm%29%5E+*%2Fetc.*+.*x%2C%24&literal=0
so I don't think it goes against any AppArmor policy or best practice.
--
You received this bug notification because you are
Thanks David for for filing this bug report. I believe you are correct
in attributing the problem to the AppArmor configuration.
** Changed in: gpsd (Ubuntu)
Status: New => Triaged
** Tags added: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, w
24 matches
Mail list logo
