**** BEGIN LOGGING AT Sat Dec 12 02:59:56 2020 Dec 12 03:11:40 aparcar[m]: is there a way to add a CI check for make package/x/refresh ? Dec 12 04:31:14 mangix: very sure there is. Like literally calling that very command. Dec 12 04:49:36 mangix: do you need more instuctions? Dec 12 04:55:48 Anyone ever built openwrt on a raspberrypi? Dec 12 05:07:26 rsalvaterra: ping Dec 12 05:19:53 meh, compiler says recompile with -fPIC but is already set: https://gist.github.com/7bc3394a88281a1b6c65f01f8423e2ce Dec 12 05:24:40 yeah that one is annoying lol Dec 12 05:25:10 i've hit it before but i don't remember what the solution was Dec 12 05:25:31 actually i dunno about "too many GOT entries for" Dec 12 05:27:53 stintel: maybe fPIC is the problem to begin with: https://git.telliq.com/gtu/packages/commit/6a90253c80fe1edd5995634b0dd6f01d503e6163 Dec 12 05:50:19 m4t: looks like it's fixed after make dirclean, but not after make clean, maybe toolchain somehow had to be rebuilt after https://git.openwrt.org/0eb2fa39 Dec 12 05:59:50 fun Dec 12 06:30:14 aparcar[m]: probably needs to be a separate workflow Dec 12 07:34:17 aparcar[m]: I've build openwrt on an mvebu platform. AMA. Dec 12 07:34:26 *built Dec 12 09:19:46 jow: FYI, I replaced my edge router and the PPPoE wan / firewall interplay issue isn't popping up anymore (was a planned replacement) Dec 12 09:21:34 i will post your instructions in the thread i linked to earlier though, hopefully the other guy can get some meaningful info then to fix it. Dec 12 12:37:28 dangole, that is interesting. something does not add up here Dec 12 12:37:55 when a file is moved the context of the file is moved with it Dec 12 12:38:38 if the filesystem that the file is moved to does not support labeling then the relabeling fails Dec 12 12:38:58 with that in mind, the sysupgrade.tgz file is moved from /boot to /? Dec 12 12:39:16 then what kind of filesystem is mounted on / at that time? Dec 12 12:39:43 also have you determined that it really fails (not just printing a permission denied message) Dec 12 12:42:09 one possible workaround would be to copy the file instead of moving it in this scenario because in this scenario a fat file system is mounted on /boot (fat doesnt support labels) but i would suspect that a different filesystem is mounted on / Dec 12 12:42:38 so in that case a move wouldnt make much sense anyway as it crossed filesystems and i guess ends up copying regardless Dec 12 12:44:15 but i am overlooking something here. it seems that the filesystem that the sysupgrade.tgz is moved to doesnt support labels ... so where is it copied to (is it reall /?) and what type of file system is mounted on there at that time? Dec 12 12:52:25 grift: / is the newly created overlayfs (sitting on top of either f2fs or ext4 lowerdir) Dec 12 12:53:54 dangole: so why move the file? Dec 12 12:54:06 its coming from a fat filesystem Dec 12 12:55:01 but regardless that still doesnt add up because the target filesystem supports labels ... so the move should have succeeded in that case Dec 12 12:57:14 also i took that for granted but youre saying that 1. it fails in enforcing mode but works in permissive mode 2. if fails in enforcing mode but there are no events in dmesg? Dec 12 12:58:34 i guess i am jumping the gun a little here. its best to follow procedure instead of jumping to all kinds conclusions Dec 12 13:02:57 grift: exactly. it fails only when enforcing, and there is nothing in dmesg Dec 12 13:03:16 grift: we could copy and subsequently delete the source file (kinda the same as mv accross filesystems) Dec 12 13:04:20 hmm if it only fails in enforcing mode then that suggests that selinux is blocking and not an issue with the code in mv Dec 12 13:05:59 weird and unlikely but a possibility that the policy blocks something that is needed silently Dec 12 13:06:42 one way to make selinux verbose is to add the -D open to secilc call inthe Makefile Dec 12 13:08:19 probably easiest to see if copying instead of moving addresses the issue Dec 12 13:09:04 if that doesnt help then i guess the next option is to build selinux-policy with -D and see if that prints applicable avc denials Dec 12 13:10:32 even though the fact that "it works in permissive mode" does not back it up, my gut feeling tells me it might be related to (old) selinux code in busybox Dec 12 13:10:53 it busybox's mv that is being used isnt it? Dec 12 13:11:29 grift: yes, it's busybox mv. I replaced it by cp && rm to see if that fixes things Dec 12 13:13:27 there are (very few) rules in the policy that tell selinux to silently block specified events. although highly unlikely it could be that such an event is hit Dec 12 13:14:04 the policy can be built without any of these "dontaudit" rules by passing -D to secilc Dec 12 13:15:32 also when i looked at your paste, it was (i think) moving the sysupgrade.tgz file to a loop device Dec 12 13:15:52 not sure how that relates to all this Dec 12 13:20:21 if i recall correctly its mountroot that does this stuff right? Dec 12 13:20:47 it's preinit, see here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/base-files/lib/preinit/79_move_config;h=444cd75e44f7bffc546630cd657a35a8ff3eacdf;hb=HEAD Dec 12 13:23:49 grift: replacing the 'mv' by 'cp && rm' did the trick Dec 12 13:25:26 interesting ... Dec 12 13:25:49 grift: sysntpd still isn't allowed to read /etc/capabilities/*.json apparently Dec 12 13:26:06 can you show avc denial? Dec 12 13:28:10 but yes not everything adds up with the mv versus cp .. but if i would have to guess then i would guess that its not a policy issue Dec 12 13:28:28 grift: https://termbin.com/0nn1 Dec 12 13:28:53 but if cp works then please consider using that, i dont see how mv makes sense cross partitions Dec 12 13:29:25 it's just a shorthand for cp && rm, ie. literally it's shorter to write that than writing cp .... && rm ... Dec 12 13:29:41 (in that case, ie. mv accross filesystems) Dec 12 13:29:44 dangole: those are old denials Dec 12 13:30:10 are you sure you build with latest policy Dec 12 13:30:34 grift: i thought so, but lemme make sure Dec 12 13:30:54 grift: that 'mv' to be replaced with 'cp && rm' was duplicated 13x to different targets :( Dec 12 13:31:18 [kcinimod@brutus selinux-policy (master=)]$ sesearch policy.31 -s rcsysntpd.subj -t capabilities.conffile -c dir -p search -A Dec 12 13:31:19 grift: so if we find a way for the mv to be ok there it'd be much nicer than replacing it 13 times Dec 12 13:31:28 allow initscript.subj_typeattr capabilities.conffile:dir { getattr search }; Dec 12 13:31:50 grift: i don't have sesearch installed Dec 12 13:32:16 yes , personally i would probably start by updating busybox selinux code (although it might turn out to be unrelated) Dec 12 13:32:19 anyhow Dec 12 13:33:04 if it turns out that you didnt have the new selinux-policy patch, as your pastebin suggests then it may be that you didnt have the fix for that mv issue either Dec 12 13:33:13 grift: i kinda see that as expected behaviour: mv keeps the label of the file, which happens to come from fatfs... Dec 12 13:33:54 but my sources confirm that atleast this event is allowed: avc: denied { search } for pid=3322 comm="sh" name="capabilities" dev="overlay" ino=4294967367 scontext=u:r:rcsysntpd.subj tcontext=u:r:capabilities.conffile tclass=dir permissive=0 Dec 12 13:33:57 grift: trying to rebuild now, did make package/selinux-policy/clean before, so now it should for sure include the most recent additions (I'm using git-src) Dec 12 13:35:05 yes the mv behavior in general is expected Dec 12 13:35:30 but not everything always handles failures well Dec 12 13:36:12 ie i would argue that a relabeling failure shouldnt cause the command to exit with a failure Dec 12 13:37:25 we have the same issue with pythons shutil.copy2() Dec 12 13:37:34 thats essentially a cp -a Dec 12 13:37:44 which copies over the extended attributes as well Dec 12 13:38:07 but if you copy to a filesystem that doesnt support extended attributes then shutil.copy2() will fail hard Dec 12 13:38:24 so basically that makes shutil.copy2() useless Dec 12 13:38:43 fortunately shutil.copy() doesnt have that issue Dec 12 13:40:35 but yes all the events in that pastebin are addressed in git ... Dec 12 13:40:48 https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=cbf6ea7e571d7c717ba2dcdeb4166658e89adfd8#patch4 Dec 12 13:41:54 so i suspect that somehow the policy wasnt updated and that then also explains (in a less far fetched way) why mv still fails Dec 12 13:43:13 also as for the /etc/firewall.user and fw3 issue, yes i know that its broadly used but fw3 is targeted because its a dependency Dec 12 13:43:49 so thats why i want to ensure that adding a rule to /etc/firewall.user and then running service firewall restart works Dec 12 13:44:21 because /etc/firewall.user gets interpretted by fw3 running iptables Dec 12 13:44:37 keep in mind that /etc/firewall.user location is configurable in 7etc/config/firewall Dec 12 13:44:51 there also may be multiple includes Dec 12 13:44:52 so need to make sure that fw3 can use iptables fd Dec 12 13:45:35 yes well if someone wants to relocate it then he should also use chcon to address labels Dec 12 13:46:10 or use cp -a /etc/firewall.user /etc/firewall1.user Dec 12 13:47:21 It is most likely packages registering new includes and creating new snipped files Dec 12 13:47:26 *snippet Dec 12 13:47:29 e.g. miniupnpd Dec 12 13:47:53 how about a /etc/firewall.user.d then? Dec 12 13:50:19 maybe Dec 12 13:51:24 have to try to maintain/encourage atleast some order Dec 12 13:51:49 because else murphies law will apply Dec 12 13:52:00 looking at https://git.defensec.nl/?p=selinux-policy.git;a=blob;f=src/net/netport/reservednetport/httpreservednetport.cil;h=34efd9770aebce1ca790f042be95ce6d8c2a1467;hb=HEAD - how are users expected to act when changing the listen_http(s) port in /etc/config/uhttpd ? Dec 12 13:53:23 yes thats food for thought ... we could address that in several way's i guess. i did add something (admittely not very solid) for sshd Dec 12 13:53:54 you can make dropbead listen on 2222 instead of 22 but its hard coded Dec 12 13:54:14 we can also just say, to hell with using selinux to control network access Dec 12 13:54:35 and just grant blanket net work access and rely on users using netfilter instead Dec 12 13:55:58 but yes currently uhttpd is only supported on tcp:443 and 80 ... Dec 12 13:56:39 ok Dec 12 13:57:26 its a work in progress Dec 12 13:58:06 integrity and "one size fits all" doesnt quite go well together Dec 12 14:00:57 i guess i could atleast add a build time option, so that policy can be build with access control over binding sockets to ports and connecting to ports or without Dec 12 14:07:32 grift: i was indeed testing an outdated version of your policy. with recent snapshot now, it works when replacing 'mv' with 'cp && rm'. Dec 12 14:08:17 grift: sadly it's done slightly different in the 13 copies of 79_move_config among the different targets using block device to boot... Dec 12 14:10:47 so it still doesnt work with mv and with my latest policy? Dec 12 14:11:16 if mv doesnt work still, then are therese any avc denials this time? Dec 12 14:13:45 things are getting confusing now, its best to follow procedure and to not assume Dec 12 14:14:13 because now in hindsight i can imagine why you said earlier: "it works in permisssive mode but not enforcing" Dec 12 14:14:30 now tht part makes sense, because you werent using the fix Dec 12 14:14:50 so now we just need to do that whole procdure again because the scenario changed Dec 12 14:17:42 jow, implementing the desired access control is a matter of minutes, but deciding what to implement is subjective and that needs sme thought Dec 12 14:17:54 initiall i created this policy to scratch an itch Dec 12 14:18:11 and so it is a bit tailored to my requirements Dec 12 14:18:28 but almost anything is possible Dec 12 14:18:59 som of these things do need some consideration though Dec 12 14:19:14 grift: yes, it works now even when using 'mv' with your updated policy Dec 12 14:19:21 LOL Dec 12 14:19:41 grift: sorry for the confusion. was me forgetting to `make clean`... Dec 12 14:19:51 fine Dec 12 14:19:56 it happens Dec 12 14:21:32 grift: ready to tag and bump the selinux-policy package, i'd say Dec 12 14:22:05 did you add a rule to /etc/firewall.user and then run service firewall restart (and check to see if the rule was added to the table)? Dec 12 14:22:53 add some random iptables command in there, then just run service firewall restart and check dmesg Dec 12 14:23:02 for example some log rule or whatever Dec 12 14:23:16 no, still: avc: denied { getattr } for pid=3294 comm="fw3" path="/etc/firewall.user" dev="overlay" ino=40 scontext=u:r:fw3.subj tcontext=u:r:file.conffile tclass=file Dec 12 14:23:35 is that permissive? Dec 12 14:23:39 no Dec 12 14:23:47 can do setenforce 0 Dec 12 14:23:48 enforcing=1 Dec 12 14:23:50 then try again? Dec 12 14:25:01 hmm that file is mislabeled as well ... Dec 12 14:25:03 sigh Dec 12 14:25:09 grift: https://termbin.com/g0fx Dec 12 14:25:13 you have a lableing issue ... Dec 12 14:25:36 grift: maybe because the firewall.user file was part of the restored config files in sysupgrade.tgz? Dec 12 14:26:19 grift: (ignore the lines about hostapd, mkdir and stuff, that's my unfinished efforts to run hostapd non-root) Dec 12 14:26:24 o right .... Dec 12 14:26:32 well no .. Dec 12 14:26:50 ? Dec 12 14:26:54 hmm does restorecon -v /etc/firewall.user reset it? Dec 12 14:27:19 can you check the label of some other file that was restored from backup? Dec 12 14:27:37 i guess for example /etc/passwd (is that backed up?) Dec 12 14:28:06 all the files in /etc/config are correctly labeled u:r:uci.conffile despite comming from the backup Dec 12 14:28:33 weird ... Dec 12 14:29:10 how did you edit that firewall.user file? with vi? Dec 12 14:30:08 some editors create scratch files and then mv them to their final destination ... Dec 12 14:30:36 which then can cause issues (but for now thats speculation) Dec 12 14:31:51 grift: yes, i edited it with vi, but before it got tar'ed (supposedly without labels) into sysupgrade.tgz and restored on the new installation Dec 12 14:31:52 anyhow i got the info i need Dec 12 14:32:05 grift: good :) Dec 12 14:32:14 yes but thats just extracting the tgz (ie just a cp) Dec 12 14:32:27 and that wouldnt have caused the labeling isssue afact Dec 12 14:41:28 dangole i pushed v0.4 Dec 12 14:41:55 but that labeling issue is weird, but since i can't produce it will table that for now Dec 12 14:44:13 o i see the bug ... Dec 12 14:44:22 damn just after i tagged Dec 12 14:45:31 i guess i ll do a v0.4.1 Dec 12 14:46:24 grift: oh no. just pushed the package update. Dec 12 14:46:51 ok well theres going to be bugs anyway Dec 12 14:47:03 so i guess that fix will have to wait for a new release Dec 12 14:47:18 https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=c3eef6aff172cac234d0522326e309398cdcc8ea Dec 12 14:48:06 grift: yes, lets see what else comes up and do another bump in the next days Dec 12 14:54:11 havent upgraded my firmware, or rebooted my router in 42 day's Dec 12 14:54:27 its runs so smooth now that i dont want to touch it Dec 12 15:20:41 i will add a rule for uhttpd to allow it to bind tcp sockets to ports > 1024 inaddition to the existing 80/443 Dec 12 15:20:52 i think thats a reasonable middle ground Dec 12 15:26:51 issue solved: https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=4b9ef6af5261678cf9f0d4b9ba7836fe6d9f131f Dec 12 15:58:11 also opened up the network for dropbear while i am at it Dec 12 18:52:25 undefined reference to `__fn_local_printf_frexpl' Dec 12 18:52:31 I have no idea what this is Dec 12 19:22:05 mangix: gnutls? Dec 12 19:25:22 mangix: "__fn_local_" seems to be a mips16 specific gcc function name mangling prefix while printf_frexpl if a GnuTLS function for ptintf'ing doubles or long doubles Dec 12 19:25:42 mangix: so... whatver is broken, maybe PKG_USE_MIPS16:=0 cures it? Dec 12 19:25:47 dangole: ping Dec 12 19:27:21 dangole: That did, in fact, fix it :) Takes forever to build now, but that'll come down once I start dividing up rust-lang and that it'll not have to rebuild that toolchain each time Dec 12 19:27:49 dangole: real 198m7.924s user 1030m49.860s sys 35m48.054s Dec 12 19:28:06 dangole: Thanks again :) Dec 12 19:55:05 jow: glib2 issue. I worked around it Dec 12 20:08:33 hmmm I can't figure out how to properly do this Dec 12 20:37:10 jow: do you plan to use luci-theme-openwrt2020 default for 20.12 release? Dec 12 20:37:53 is 20.12 decided upon then? :^) Dec 12 20:39:21 somehow, yes Dec 12 20:42:45 hehe. that's great :) Dec 12 20:52:27 oh I remember 21.01 :P Dec 12 20:55:07 IIRC we've branched 19.07 in July 2019 and released in January 2020 :p Dec 12 20:55:33 so we can still branch 20.12 on 31.12.2020 and relase in June :) Dec 12 20:55:57 let's see how this pans out Dec 12 20:57:50 :P Dec 12 20:57:55 :P Dec 12 20:57:59 i like your optimism though. Dec 12 20:58:44 i'm not pining as much for an actual release as i am for a release branch. less things in flux than plain master. Dec 12 21:42:23 ynezz: good question Dec 12 21:42:45 ynezz: I don't see why not, but I also do know that people dislike ui changes on principle, so not sure Dec 12 21:43:31 due to the use of that design specific webfont it is also somewhat larger Dec 12 21:43:48 on the other hand it works way better with mobile devices Dec 12 22:53:16 Just troubleshooted an issue where a legacy non-RSN capable (non-WPA2 capable) client could not connect to OpenWRT - had to manually set the EAPOL version to v1 instead of v2 Dec 12 22:53:51 This makes sense as 802.11i (RSN) for WPA2 came in 2004, and 802.1X-2004 (EAPOLv2) came at the same time Dec 12 22:55:05 I've submitted a pull request to fix this so that EAPOLv1 is used where WPA is enabled: https://github.com/openwrt/openwrt/pull/3679 Dec 12 22:56:44 Seems this was missed as hostapd.conf upstream documents: "However, there are many client implementations that do not handle Dec 12 22:56:45 # the new version number correctly (they seem to drop the frames completely)." Dec 12 23:02:36 wow I never even had my hands on a device that didn't support WPA2 Dec 12 23:42:39 stintel: original PSP Dec 13 00:08:01 Anyone tell me what host build systems will reasonally be used to build openwrt? x86_64, aarch? powerpc/powerpc64/powerpc64le? Dec 13 00:08:56 Windows variants Dec 13 00:09:17 I at a guess, 64 bit Linux systems will be the most widely used. Dec 13 00:14:04 dorf: Yeah, and probably mac and WSL.. I may just leave them all in, in case someone wants to do something crazy down the line like building openwrt on.. whatever s390x-unknown-linux-gnu is Dec 13 00:14:49 sure.. windows/mac/linux.. ppc? not so much. Dec 13 00:17:48 dorf: https://gist.github.com/Grommish/c81cbba923b94afda63f3f84c69d1e88 is the list I'm working with (i'm still grouping them) Dec 13 00:18:45 build #751 of sunxi/cortexa53 is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/751 blamelist: Daniel Golle Dec 13 00:20:21 rather you than me, Grommish :) Dec 13 00:21:00 haha I mean, that's the list of triples I'm working to pair down.. or not. it may not be worth the time to sort them Dec 13 00:21:28 but I could see mangix building Openwrt on a mipsel-sony-psp :D Dec 13 00:22:37 but it was why I was asking hehe I don't see a need for it other than because it could Dec 13 00:47:58 build #548 of ath79/tiny is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/548 blamelist: Daniel Golle Dec 13 00:56:24 build #542 of ipq40xx/generic is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/542 blamelist: Daniel Golle **** ENDING LOGGING AT Sun Dec 13 02:59:56 2020