=== ephemer0l is now known as GeneralDiscourse
[01:27] <blahdeblah> I just found a really annoying bug in the apparmor profile shipped with chrony.  This person found it earlier: https://askubuntu.com/questions/1411005/could-not-open-run-chrony-chronyd-pid-permission-denied
[01:27] <blahdeblah> I can't find any project to report this against in LP.  Any suggestions?
[01:28] <blahdeblah> It just needs `@{run}/chrony/{,**} rw,` in the apparmor profile instead of `@{run}/chrony/{,*} rw,`
[01:30] <arraybolt3> `ubuntu-bug chrony` might do the trick.
[01:31] <arraybolt3> That should upload some debugging info and then give you the ability to fill out a bug report form.
[01:40] <blahdeblah> I should remember that by now... :-)  Thanks arraybolt3
[01:40] <jjohansen> blahdeblah: if its apparmor related, and you aren't sure. Just file it against apparmor in lp https://bugs.launchpad.net/ubuntu/+source/apparmor
[01:41] <jjohansen> or against the upstream project in gitlab https://gitlab.com/apparmor/apparmor/-/issues
[01:41] <sarnold> heya blahdeblah :)
[01:41] <blahdeblah> jjohansen: The file is shipped in the chrony package, so seems like it probably should be raised against that?
[01:41] <blahdeblah> \o sarnold
[01:42] <jjohansen> blahdeblah: sure, but if you aren't sure etc. better to report it, the apparmor people can always add affected packages in lp etc
[01:42] <blahdeblah> Cool - thanks
=== chris14_ is now known as chris14
=== chris14_ is now known as chris14
[07:03] <cpaelzer> hi blahdeblah, gladly I highlight on chrony and can see the bug now - https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/2004525 it is
[07:03] -ubottu:#ubuntu-security- Launchpad bug 2004525 in chrony (Ubuntu) "Fatal error : Could not open /run/chrony/chronyd.pid : Permission denied" [Undecided, Incomplete]
[07:03] <cpaelzer> thanks
[07:12] <cpaelzer> hmm, so far I agree to amurray
[07:12] <cpaelzer> a few more things to check ...
[07:33] <blahdeblah> amurray, cpaelzer: Thanks for looking.  Weird problem; what other data should I try to gather?
[07:34] <blahdeblah> I can back out my override and try again, I guess..
[07:39] <cpaelzer> blahdeblah: hi
[07:39] <cpaelzer> blahdeblah: I'm currently checking and upgrading a few older chrony systems of mine
[07:39] <cpaelzer> blahdeblah: so far, no issue here
[07:39] <cpaelzer> blahdeblah: but I've found a theory
[07:39] <cpaelzer> blahdeblah: the path changed from /run/chrony.pid to /run/chrony/chrony.pid
[07:40] <cpaelzer> blahdeblah: that was also adapted in the profile
[07:40] <cpaelzer> blahdeblah: but, if you'd have kept the old profile of focal - then it would show the issue you have
[07:40] <cpaelzer> blahdeblah: what does `grep 'run.*/chrony' /etc/apparmor.d/usr.sbin.chronyd` give you?
[07:40] <blahdeblah> Yeah - I definitely checked that. It's correct.
[07:41] <blahdeblah> So I commented out the line and it still works.  This upgrade did go a little pear-shaped on me and failed halfway through.
[07:41] <blahdeblah> I had to manually massage a few packages back into life.  Maybe one of them did something strange.
[07:41] <blahdeblah> The upgrade seemed to have problems with duplicated utilities in /bin vs. /usr/bin.  I know on new systems they're just symlinked from / into /usr, but IIRC the old layout is kept on upgrades?
[07:41] <cpaelzer> blahdeblah: so you already have the new rule (having @{run}/chrony/{,*} rw,), and still without the one you suggested (@{run}/chrony/{,**} rw,) it doesn't work for you ?
[07:42] <cpaelzer> odd
[07:42] <cpaelzer> the next upgrade I'm running is an rpi4 which is a bit slower, but so far I can't recreate the issue :-/
[07:43] <cpaelzer> blahdeblah: just for completeness, could you remove the rule you added and report the full apparmor denial message int he bug?
[07:44] <blahdeblah> cpaelzer: Output you asked for: https://pastebin.ubuntu.com/p/YY2Vj4pTzV/
[07:45] <blahdeblah> But the thing is, now it works, without the override.
[07:45] <cpaelzer> umm, what
[07:45] <blahdeblah> yeah, weird
[07:45] <blahdeblah> I'll see if there was a deny in my logs
[07:46] <blahdeblah> (from apparmor)
[07:46] <cpaelzer> yep, thanks
[07:46] <cpaelzer> so what might we look at then, dh_apparmor not issuing a reload of the profile maybe?
[07:46] <cpaelzer> well, let us start with the denial in your logs
[07:48] <blahdeblah> No denial ;-( https://pastebin.ubuntu.com/p/Vpk3dSYYg3/
[07:49] <cpaelzer> so the "apparmor fix" was a red herring?
[07:49] <blahdeblah> Seems like it. :-(
[07:51] <cpaelzer> I updated the bug with all we discussed
[07:51] <blahdeblah> A number of systemd files ended up with old versions in /usr/bin and new versions in /bin, and I had to move the old ones aside to complete the upgrade, so it might be that one of those was interfering with apparmor profile loads?
[07:51] <cpaelzer> I hope to get the issue on my system that is upgrading in background
[07:51] <cpaelzer> well, if it would not have loaded the new apparmor, then it would have had a denial
[07:51] <blahdeblah> Yeah, you would think so... :-\
[07:52] <cpaelzer> oh wait
[07:52] <cpaelzer> maybe it is vice versa
[07:52] <blahdeblah> The fact that one other person in the world had it suggests to me that there is some kind of obscure bug involved, but I honestly don't think it's worth chasing down.  I think I'll close the bug now that I can't reproduce.
[07:52] <cpaelzer> PIDFile=/run/chrony/chronyd.pid is an entry in the .service file
[07:52] <cpaelzer> maybe it was using the wrong path there due to your systemd service confusion
[07:52] <cpaelzer> scrolling to your old systemctl status in the bug ...
[07:53] <cpaelzer> none there and it isn't seen in the askubuntu post
[07:54] <cpaelzer> too bad, I had hoped we might find evidence of it using the wrong path there
[08:02] <cpaelzer> I'm looking into file permissions
[08:02] <cpaelzer> and hoping to find something with my last system upgrading
[08:03] <cpaelzer> but if not, then this will have to stay incomplete for now :-/
=== cpaelzer_ is now known as cpaelzer
[18:45] <sdeziel> is there any use to have a source.list entry for security.ubuntu.com when one uses {uk,us}.archive.ubuntu.com which are AFAIK, 2 official primary mirrors run by Canonical directly? AFAIK, security.ubuntu.com is there to ensure a non-Canonical run mirror starts lagging and doesn't publish security fixes quickly enough
[19:37] <tomreyn> sdeziel: https://wiki.ubuntu.com/SecurityTeam/FAQ#What_repositories_and_pockets_should_I_use_to_make_sure_my_systems_are_up_to_date.3F
[19:38] <tomreyn> my understanding is it's not just about who maintains the mirrors but also about how timely updates are pushed to them
[19:38] <tomreyn> (and to the different pockets)
[19:40] <sdeziel> tomreyn: AFAIK, stuff going to -security goes to -updates soon after so that's one reason, are you aware of another? I'm asking cause we are talking about few minutes or maybe hours
[19:41] <tomreyn> sdeziel: i'm not, but i'm not leosilva (who, according to the /topic, could potentially answer your question)
[19:45] <mdeslaur> sdeziel: there's no guarantee that mirrors won't enter us and uk, but if it's just canonical ips, there's no reason for security.
[19:46] <sdeziel> mdeslaur: oh interesting, thanks!
[19:46] <mdeslaur> yes, security.u.c is to prevent a laggy mirror from not having the latest updates
[19:47] <mdeslaur> hrm, I wonder why the uk and us mirors aren't under us and uk https://launchpad.net/ubuntu/+archivemirrors
[19:59] <sarnold> wild guessing, that list is generated by the mirror prober script, and that's not going to be checking our own mirrors
[20:03] <mdeslaur> yeah, but aren't public mirrors part of our round-robin dns thingy?
[20:13] <sarnold> we'll use the public mirrors for many of the other country-specific mirrors, eg se.archive.ubuntu.com is donated; a lot of countries have an in-country or nearby-country mirror. I don't *think* those are round-robind, though, I think each country gets *one* such mirror, to prevent problems due to different sync frequencies