[PATCH cgi-io] main: allow underscore character in filename/mimetype
From: Chen Minqiang
This add underscore character to valid char list in filename or in
mimetype. It is not usual but should theoretically be valid.
Signed-off-by: Chen Minqiang
---
main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/main.c b/main.c
index 8ca4c04..9e715de 100644
--- a/main.c
+++ b/main.c
@@ -547,11 +547,11 @@ main_download(int argc, char **argv)
return failure(403, 0, "Requested path is not a regular file or
block device");
for (p = fields[5]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-", *p))
+ if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-_", *p))
return failure(400, 0, "Invalid characters in
filename");
for (p = fields[7]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" .;=/-", *p))
+ if (!isalnum(*p) && !strchr(" .;=/-_", *p))
return failure(400, 0, "Invalid characters in
mimetype");
rfd = open(fields[3], O_RDONLY);
@@ -745,11 +745,11 @@ main_exec(int argc, char **argv)
return failure(403, 0, "Exec permission denied");
for (p = fields[5]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-", *p))
+ if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-_", *p))
return failure(400, 0, "Invalid characters in
filename");
for (p = fields[7]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" .;=/-", *p))
+ if (!isalnum(*p) && !strchr(" .;=/-_", *p))
return failure(400, 0, "Invalid characters in
mimetype");
args = fields[3] ? parse_command(fields[3]) : NULL;
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] main: allow underscore character in filename/mimetype
From: Chen Minqiang
This add underscore character to valid char list in filename or in
mimetype. It is not usual but should theoretically be valid.
Signed-off-by: Chen Minqiang
---
main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/main.c b/main.c
index 8ca4c04..9e715de 100644
--- a/main.c
+++ b/main.c
@@ -547,11 +547,11 @@ main_download(int argc, char **argv)
return failure(403, 0, "Requested path is not a regular file or
block device");
for (p = fields[5]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-", *p))
+ if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-_", *p))
return failure(400, 0, "Invalid characters in
filename");
for (p = fields[7]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" .;=/-", *p))
+ if (!isalnum(*p) && !strchr(" .;=/-_", *p))
return failure(400, 0, "Invalid characters in
mimetype");
rfd = open(fields[3], O_RDONLY);
@@ -745,11 +745,11 @@ main_exec(int argc, char **argv)
return failure(403, 0, "Exec permission denied");
for (p = fields[5]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-", *p))
+ if (!isalnum(*p) && !strchr(" ()<>@,;:[]?.=%-_", *p))
return failure(400, 0, "Invalid characters in
filename");
for (p = fields[7]; p && *p; p++)
- if (!isalnum(*p) && !strchr(" .;=/-", *p))
+ if (!isalnum(*p) && !strchr(" .;=/-_", *p))
return failure(400, 0, "Invalid characters in
mimetype");
args = fields[3] ? parse_command(fields[3]) : NULL;
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reaching out to Greg KH for 6 year LTS kernel versions
I am not on the openwrt-devel list from this acct... I tried to resubscribe but its taking too long... On Wed, Aug 10, 2022 at 1:29 PM Philip Prindeville wrote: > > Not to play the devil's advocate but... do we want old kernels hanging out > that long? People are still shipping 3.3 kernels. > Besides not encouraging people to update to new releases that mitigate > discovered CVE's, we'd also not pick up David Taht's excellent improvements > in Buffer Bloat. People keep giving me too much credit. There have been dozens of core contributors to this effort, 1000s of others, and we have billions of machines (not enough routers, tho!) now doing more of the right things. I haven't made a technical contribution in years. I( got a couple new things that I'd like to work on, but no funding). What was once a 5-7 lag in embedded from devel to distribution now seems closer to 10. I've gone political in search of finding ways to get bufferbloat fixes out there. Somehow convincing the world that in addition to burning billions on fiber buildouts ISPs should be supplying better routers has been a big goal, and I'm low on ideas on how to move forward on that. Certainly finding some way to get openwrt shippers like starlink to at least plan to upgrade to a modern openwrt rather than continue to ship LEDE is very desirable... 6 year old kernels at FCS noo... I thought ooka's new speedtest (which measures responsiveness on up/downloads now) would provide a tipping point. Certainly also preseem and libreqos are making an impact in the smaller ISP markets... In the last 6 months of coping with a string of regressions in openwrt's wifi[1], I've reflected on the waddington effect a lot. If you haven't heard of it, it applies a string of criteria to how and why you o prevenntative maintenence on airplanes: https://resources.savvyaviation.com/wp-content/uploads/articles_eaa/EAA_2011-03_the-waddington-effect.pdf As for 6 years on a LTS kernel, my instinct is NO! Progress MUST be made! We must keep working towards making kernel upgrades continuous and easy. But think deeply on the waddington effect. The cold and bitter reality though is if someone is willing to pay someone(s) to maintain a kernel for that long, and it keeps up with major security issues, it's no skin off our backs. I would prefer cash be injected into better review ( there are 1500 open issues and 300+ outstanding https://github.com/openwrt/openwrt/pulls right now), we found ways to attract, train, and retain good developers in "the FOSS way", and more companies and governments using openwrt found ways to support those, and "sufficiently rapid" change in the ever more fossilized FOSS ecosystem. [1] https://www.linkedin.com/feed/update/urn:li:activity:6963337312596369408/ > > > On Aug 8, 2022, at 5:15 PM, Florian Fainelli wrote: > > > > Hi, > > > > Greg KH has communicated a few times before on his blog [1] that he is > > seeking the help of individuals and company to help him maintain the LTS > > kernels and allow them to be made 6 years instead of just the usual 2 years. > > > > 5.10 is a 6 year LTS, but 5.15 is not listed as such, although it certainly > > would make sense for it to be since we use 5.15 in OpenWrt. > > > > It would be good for the project to have a designated contact who can > > communicate the kernel version plan ahead of time, or once a LTS is picked > > up, we could sign up people to do regular testing of the stable release > > candidates? > > > > Thoughts? > > > > [1]: > > http://kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/ > > -- > > Florian > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firewall4] fw4: add support for include.d dir
Hi,
> [...]
>
> Sorry, but I don't agree with the following reasons. Let me briefly explain
> why.
>
> All files under '/usr/share/firewall4/includes.d' are uci files. I can see
> all relevant options.
One problem with your suggested implementation is that you introduce a generic
directory (/usr/share/firewall4/includes.d) containing uci partials that do
look like a full /etc/config/firewall but actually ignore all section types
except `config include` ones, that will lead to confusion.
> I can set in the includes my own path. This is
> relevant for packages that updates the ruleset on events. If I do not want
> to be this rules persistent saved I could use a tmp file in the system
> (strongswan).
Using my proposal you could achieve the same by placing a symlink to a
temporary file path
> Also the new include add by you already does have the state file feature.
> Which is relevant on reloading the ruleset.
Not sure what you mean with that.
> In addition, it would make the ruleset.uc file confusing if I added the
> same feature again.
The ruleset.uc file wouldn't change at all. The implementation would be
confined to fw4.uc, like your approach.
> Also, I would have to add two sections on include to support temporary
> rules, which I would not have to store under
> '/usr/share/firewall4/includes.d/' but under '/tmp/firewall4/includes.d/'
> for example to support the not persistent feature.
ln -s /tmp/strongswan/nftables.d/pre-input.nft \
/usr/share/nftables.d/chain-pre/input/10_strongswan.nft
ln -s /tmp/strongswan/nftables.d/pre-output.nft \
/usr/share/nftables.d/chain-pre/output/10_strongswan.nft
ln -s /tmp/strongswan/nftables.d/pre-forward.nft \
/usr/share/nftables.d/chain-pre/forward/10_strongswan.nft
> We also use the include to add the helpers.
Can you elaborate?
> Last but not leased, if we now add an other possibility, then I don't
> think anyone knows where which file adds which rule!
The same applies to /usr/share/firewall4/includes.d/ as well. You do need to
be aware of it to know that includes can stem from there.
> From my point of view, it makes sense to use the include function from you
> with my extension. So I think the include feature is the better and
> unified solution.
What I do not like about it are several facts:
- It introduces uci in a non-standard location
- It implies configurability where there isn't any (it is package managed
resource files, like init scripts. Technically you can edit init scripts
but they're certainly not configuration but package integration code).
- It introduces overhead; you do have to read and parse a uci file to extract
a path from it which you then write into the ruleset so that nftables can
include it
- It creates the false impression of being a general-purpose uci partial
solution to be able to modularize /etc/config/firewall which it isn't since
it'll silently ignore any non-include section type being put there
I have attached my proposal as patch for reference.
Kind regards,
Jo
From 5ab0f61350f02590c5e6c1981bce4531510517de Mon Sep 17 00:00:00 2001
From: Jo-Philipp Wich
Date: Thu, 11 Aug 2022 13:48:14 +0200
Subject: [PATCH] fw4: support automatic includes
Introduce a new directory tree /usr/share/nftables/includes.d/ which may
contain partial nftables files being included into the rendered ruleset.
The include position is derived from the file path;
- Files in .../includes.d/table-pre/ and .../includes.d/table-post/ are
included before and after the `table inet fw4 { ... }` declaration
respectively
- Files in .../includes.d/ruleset-pre/ and .../includes.d/ruleset-post/
are included before the first chain and after the last chain
declaration within the fw4 table respectively
- Files in .../includes.d/chain-pre/${chain}/ and .../chain-post/${chain}/
are included before the first and after the last rule within the mentioned
chain of the fw4 table respectively
Automatic includes can be disabled by setting the `auto_includes` option to
`0` in the global defaults section.
Signed-off-by: Jo-Philipp Wich
---
root/usr/share/ucode/fw4.uc | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/root/usr/share/ucode/fw4.uc b/root/usr/share/ucode/fw4.uc
index 2dc44ac..86e3331 100644
--- a/root/usr/share/ucode/fw4.uc
+++ b/root/usr/share/ucode/fw4.uc
@@ -733,6 +733,19 @@ return {
this.cursor.foreach("firewall", "include", i => self.parse_include(i));
+ //
+ // Discover automatic includes
+ //
+
+ if (this.default_option("auto_includes")) {
+ for (let position in [ 'ruleset-pre', 'ruleset-post', 'table-pre', 'table-post', 'chain-pre', 'chain-post' ])
+for (let chain in (position in [ 'chain-pre', 'chain-post' ]) ? fs.lsdir(`/usr/share/nftables/includes.d/${position}`) : [ null ])
+ for (let path in fs.glob(`/usr/share/nftables/includes.d/${position}/${chain ?? ''}/*.nft`))
+ if (fs.access(path))
+ this.parse_include({ typ
[PATCH] hostapd: add mbo flag to get_clients ubus method
There is no WLAN_STA_MBO flag, but according to the hostapd source code, when an STA does not support MBO, cell_capa will be 0. Use this to indicate MBO support in the get_clients ubus method. Signed-off-by: Stijn Tintel --- package/network/services/hostapd/src/src/ap/ubus.c | 4 1 file changed, 4 insertions(+) diff --git a/package/network/services/hostapd/src/src/ap/ubus.c b/package/network/services/hostapd/src/src/ap/ubus.c index 182aae7d05..622eab8838 100644 --- a/package/network/services/hostapd/src/src/ap/ubus.c +++ b/package/network/services/hostapd/src/src/ap/ubus.c @@ -318,6 +318,10 @@ hostapd_bss_get_clients(struct ubus_context *ctx, struct ubus_object *obj, blobmsg_add_u8(&b, sta_flags[i].name, !!(sta->flags & sta_flags[i].flag)); +#ifdef CONFIG_MBO + blobmsg_add_u8(&b, "mbo", !!(sta->cell_capa)); +#endif + r = blobmsg_open_array(&b, "rrm"); for (i = 0; i < ARRAY_SIZE(sta->rrm_enabled_capa); i++) blobmsg_add_u32(&b, "", sta->rrm_enabled_capa[i]); -- 2.35.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: extract kmod-sched-act-ipt from kmod-sched
There is only one module in kmod-sched that depends on iptables. Move it to its own kmod package so we can drop the kmod-ipt-core dependency from kmod-sched. This makes it possible to disable all kmod-ipt-* packages without having to disable kmod-sched. Signed-off-by: Stijn Tintel --- package/kernel/linux/modules/netsupport.mk | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 5369be201f..be0347527d 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -775,6 +775,22 @@ endef $(eval $(call KernelPackage,sched-act-sample)) +define KernelPackage/sched-act-ipt + SUBMENU:=$(NETWORK_SUPPORT_MENU) + TITLE:=IPtables targets + DEPENDS:=+kmod-ipt-core +kmod-sched-core + KCONFIG:=CONFIG_NET_ACT_IPT + FILES:=$(LINUX_DIR)/net/sched/act_ipt.ko + AUTOLOAD:=$(call AutoProbe, act_ipt) +endef + +define KernelPackage/sched-act-ipt/description + Allows to invoke iptables targets after successful classification. +endef + +$(eval $(call KernelPackage,sched-act-ipt)) + + define KernelPackage/sched-act-vlan SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=Traffic VLAN manipulation @@ -948,13 +964,13 @@ endef $(eval $(call KernelPackage,bpf-test)) -SCHED_MODULES_EXTRA = sch_codel sch_dsmark sch_gred sch_multiq sch_sfq sch_teql sch_fq sch_pie act_ipt act_pedit act_simple act_csum em_cmp em_nbyte em_meta em_text +SCHED_MODULES_EXTRA = sch_codel sch_dsmark sch_gred sch_multiq sch_sfq sch_teql sch_fq sch_pie act_pedit act_simple act_csum em_cmp em_nbyte em_meta em_text SCHED_FILES_EXTRA = $(foreach mod,$(SCHED_MODULES_EXTRA),$(LINUX_DIR)/net/sched/$(mod).ko) define KernelPackage/sched SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=Extra traffic schedulers - DEPENDS:=+kmod-sched-core +kmod-ipt-core +kmod-lib-crc32c +kmod-lib-textsearch + DEPENDS:=+kmod-sched-core +kmod-lib-crc32c +kmod-lib-textsearch KCONFIG:= \ CONFIG_NET_SCH_CODEL \ CONFIG_NET_SCH_DSMARK \ @@ -964,7 +980,6 @@ define KernelPackage/sched CONFIG_NET_SCH_TEQL \ CONFIG_NET_SCH_FQ \ CONFIG_NET_SCH_PIE \ - CONFIG_NET_ACT_IPT \ CONFIG_NET_ACT_PEDIT \ CONFIG_NET_ACT_SIMP \ CONFIG_NET_ACT_CSUM \ -- 2.35.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firewall4] fw4: add support for include.d dir
Hi, Sorry for the late reply instead of introducing uci includes that configure nft includes, why not encode the chain/position etc. values directly into the path/filename and directly include the file if it exists at the expected location? I was just wondering why not use the new feature you added to give other packages the ability to add rules to fw4. The include feature was exactly what was missing for fw4 to add the posibility for other package adding firewall rules to fw4(nftables=. I think the above would be a lot more manageable since you'd just have to place partial .nft files which are then folded into the final ruleset on fw4 start/reload. Sorry, but I don't agree with the following reasons. Let me briefly explain why. All files under '/usr/share/firewall4/includes.d' are uci files. I can see all relevant options. I can set in the includes my own path. This is relevant for packages that updates the ruleset on events. If I do not want to be this rules persistent saved I could use a tmp file in the system (strongswan). Also the new include add by you already does have the state file feature. Which is relevant on reloading the ruleset. In addition, it would make the ruleset.uc file confusing if I added the same feature again. Also, I would have to add two sections on include to support temporary rules, which I would not have to store under '/usr/share/firewall4/includes.d/' but under '/tmp/firewall4/includes.d/' for example to support the not persistent feature. We also use the include to add the helpers. Last but not leased, if we now add an other possibility, then I don't think anyone knows where which file adds which rule! From my point of view, it makes sense to use the include function from you with my extension. So I think the include feature is the better and unified solution. Best Regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
