=== ephemer0l is now known as GeneralDiscourse | ||
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:27 |
blahdeblah | It just needs `@{run}/chrony/{,**} rw,` in the apparmor profile instead of `@{run}/chrony/{,*} rw,` | 01:28 |
arraybolt3 | `ubuntu-bug chrony` might do the trick. | 01:30 |
arraybolt3 | That should upload some debugging info and then give you the ability to fill out a bug report form. | 01:31 |
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:40 |
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:41 |
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 | 01:42 |
=== chris14_ is now known as chris14 | ||
=== chris14_ is now known as chris14 | ||
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:03 |
cpaelzer | hmm, so far I agree to amurray | 07:12 |
cpaelzer | a few more things to check ... | 07:12 |
blahdeblah | amurray, cpaelzer: Thanks for looking. Weird problem; what other data should I try to gather? | 07:33 |
blahdeblah | I can back out my override and try again, I guess.. | 07:34 |
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:39 |
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:40 |
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:41 |
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:42 |
cpaelzer | blahdeblah: just for completeness, could you remove the rule you added and report the full apparmor denial message int he bug? | 07:43 |
blahdeblah | cpaelzer: Output you asked for: https://pastebin.ubuntu.com/p/YY2Vj4pTzV/ | 07:44 |
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:45 |
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:46 |
blahdeblah | No denial ;-( https://pastebin.ubuntu.com/p/Vpk3dSYYg3/ | 07:48 |
cpaelzer | so the "apparmor fix" was a red herring? | 07:49 |
blahdeblah | Seems like it. :-( | 07:49 |
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:51 |
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:52 |
cpaelzer | none there and it isn't seen in the askubuntu post | 07:53 |
cpaelzer | too bad, I had hoped we might find evidence of it using the wrong path there | 07:54 |
cpaelzer | I'm looking into file permissions | 08:02 |
cpaelzer | and hoping to find something with my last system upgrading | 08:02 |
cpaelzer | but if not, then this will have to stay incomplete for now :-/ | 08:03 |
=== cpaelzer_ is now known as cpaelzer | ||
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 | 18:45 |
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:37 |
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:38 |
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:40 |
tomreyn | sdeziel: i'm not, but i'm not leosilva (who, according to the /topic, could potentially answer your question) | 19:41 |
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:45 |
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:46 |
mdeslaur | hrm, I wonder why the uk and us mirors aren't under us and uk https://launchpad.net/ubuntu/+archivemirrors | 19:47 |
sarnold | wild guessing, that list is generated by the mirror prober script, and that's not going to be checking our own mirrors | 19:59 |
mdeslaur | yeah, but aren't public mirrors part of our round-robin dns thingy? | 20:03 |
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 | 20:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!