Re: [OpenWrt-Devel] Possible security issue
Maybe it should be something like:
```bash
groupadd ubus
for user in "root ..."; do
usermod -a -G ubus "${user}"
done
chgrp ubus /sbin/uci /var/run/ubus.sock
chmod g+rw /var/run/ubus.sock
chmod g+rwx /sbin/uci
chmod o-rwx /sbin/uci /var/run/ubus.sock
```
What would this break?
https://openwrt.org/docs/techref/ubus
...
Better sandboxing in procd than chroot could be an objective. IDK where the
previous discussions are?
https://openwrt.org/docs/techref/procd
cgroups without systemd:
https://wiki.archlinux.org/index.php/cgroups#With_libcgroup
Notes re: SELinux (and containers)
https://github.com/rancher/k3s/issues/1372#issuecomment-581797716
https://blog.openshift.com/securing-kubernetes/
>
> The main thing to understand about SELinux integration with OpenShift
>> is that, by default, OpenShift runs each container as a random uid and is
>> isolated with SELinux MCS labels. The easiest way of thinking about MCS
>> labels is they are a dynamic way of getting SELinux separation without
>> having to create policy files and run restorecon.
>>
>> If you are wondering why we need SELinux and namespaces at the same
>> time, the way I view it is namespaces provide the nice abstraction but are
>> not designed from a security first perspective. SELinux is the brick wall
>> that’s going to stop you if you manage to break out of (accidentally or on
>> purpose) from the namespace abstraction.
>>
>> CGroups is the remaining piece of the puzzle. Its primary purpose
>> isn’t security, but I list it because it regulates that different
>> containers stay within their allotted space for compute resources (cpu,
>> memory, I/O). So without cgroups, you can’t be confident your application
>> won’t be stomped on by another application on the same node.
>>
>
Everybody's doing it:
https://en.wikipedia.org/wiki/Seccomp#Software_using_seccomp_or_seccomp-bpf
On Sat, Apr 18, 2020 at 10:22 PM Joel Wirāmu Pauling
wrote:
> I'm sorry for wading into this. As with any security related discussion
> strawpeople can be made to support any particular thread pulling into
> infinity.
>
> Would I love to see namespaces used as part of the base Openwrt
> architecture; absolutely. It's been discussed in the past; routing in
> particular would benefit immensely from this ; use of different routing
> table ID's is a step towards that, but complications like passing device
> id's in and out of namespaces however for the switch side of things is
> problematic and adds additional overhead as will it introduce issues at the
> expense of separation and flexibility.
>
> That potentially could mitigate some of your concerns, but I feel the
> preposition for me is openwrt is not multi-user by default OOTB for most
> (if not all) targets; and if you want it to be you can.
>
> So fiddling inode bitmasks is not addressing anything IMNSHO because of
> that fact.
>
>
>
>
>
>
> On Sat, 18 Apr 2020 at 00:50, Wes Turner wrote:
>
>> From a least privileges perspective:
>>
>> - chmod o-rwx /var/run/hostapd-phyX.conf
>> - chmod o-x uci # setfacl?
>>
>> Compromise of a service running as a different user should not result in
>> disclosure of sensitive keys only necessary for different services.
>>
>> https://openwrt.org/docs/guide-user/security/security-features mentions
>> procd jail / chroot?
>>
>> AFAIU, LXC is not available in the default kernel builds in any router?
>> LXC would be an additional layer of defenses over and above chroot, which
>> isn't seccomp
>>
>> On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling
>> wrote:
>>
>>> No. If you have physical access to the node and/or a valid login as
>>> Admin then any form of PSK is vulnerable.
>>>
>>> If you are concerned about PSK's being exposed then you have the option
>>> to run 802.1x auth and issue issues tokens out of radius/IDM that is
>>> secured elsewhere than on the AP itself.
>>>
>>> On Fri, 17 Apr 2020 at 20:16, e9hack wrote:
>>>
Hi,
the configuration files for hostapd (/var/run/hostapd-phyX.conf) are
readable for everyone. This means everyone can read the wifi passwords. If
a non privileged user calls 'uci show wireless', he will also get all wifi
passwords. This possible e.g. for user nobody and dnsmasq.
Is this a a security issue?
Regards,
Hartmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Possible security issue
I'm sorry for wading into this. As with any security related discussion strawpeople can be made to support any particular thread pulling into infinity. Would I love to see namespaces used as part of the base Openwrt architecture; absolutely. It's been discussed in the past; routing in particular would benefit immensely from this ; use of different routing table ID's is a step towards that, but complications like passing device id's in and out of namespaces however for the switch side of things is problematic and adds additional overhead as will it introduce issues at the expense of separation and flexibility. That potentially could mitigate some of your concerns, but I feel the preposition for me is openwrt is not multi-user by default OOTB for most (if not all) targets; and if you want it to be you can. So fiddling inode bitmasks is not addressing anything IMNSHO because of that fact. On Sat, 18 Apr 2020 at 00:50, Wes Turner wrote: > From a least privileges perspective: > > - chmod o-rwx /var/run/hostapd-phyX.conf > - chmod o-x uci # setfacl? > > Compromise of a service running as a different user should not result in > disclosure of sensitive keys only necessary for different services. > > https://openwrt.org/docs/guide-user/security/security-features mentions > procd jail / chroot? > > AFAIU, LXC is not available in the default kernel builds in any router? > LXC would be an additional layer of defenses over and above chroot, which > isn't seccomp > > On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling > wrote: > >> No. If you have physical access to the node and/or a valid login as Admin >> then any form of PSK is vulnerable. >> >> If you are concerned about PSK's being exposed then you have the option >> to run 802.1x auth and issue issues tokens out of radius/IDM that is >> secured elsewhere than on the AP itself. >> >> On Fri, 17 Apr 2020 at 20:16, e9hack wrote: >> >>> Hi, >>> >>> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are >>> readable for everyone. This means everyone can read the wifi passwords. If >>> a non privileged user calls 'uci show wireless', he will also get all wifi >>> passwords. This possible e.g. for user nobody and dnsmasq. >>> >>> Is this a a security issue? >>> >>> Regards, >>> Hartmut >>> >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >> > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck
On Sat, Apr 18, 2020 at 2:22 AM Kevin 'ldir' Darbyshire-Bryant wrote: > > > > > On 18 Apr 2020, at 01:56, Rosen Penev wrote: > > > > On Fri, Apr 17, 2020 at 1:50 AM wrote: > >> > >>> > >>> - [ $log_buffer_size -eq 0 -a $log_size -gt 0 ] && > >>> log_buffer_size=$log_size > >>> - [ $log_buffer_size -eq 0 ] && log_buffer_size=64 > >>> + [ "$log_buffer_size" -eq 0 ] && [ "$log_size" -gt 0 ] && > >> > >> I'm never sure whether a comparison [ "$string" -eq 0 ], i.e. one with > >> quotes and one without using -eq works as expected in all cases. > >> I typically use [ "$string" = "0" ] instead, but I'm not sure whether > >> that's effectively just the same. > > Sounds bogus. log_buffer_size and log_size are stated to be uintegers above. > >> > >> Rest seems fine, despite some similar cases with -eq/-ne below. > > -eq/-ne vs = is a stylistic difference. > > I disagree. ‘= != < >’ are string comparisons, -eq/-ne/gt/lt/ge/le are > numeric/arithmetic comparisons. These are not strings. These are integers. I did as was asked and shellcheck now complains: SC2071: > is for string comparisons. Use -gt instead. > > Consider this slightly contrived case where to emphasise the difference > between string and numeric comparison I compare to ’00’ which is > arithmetically zero, but not just a simple, lone ‘0’ string. > > #!/bin/sh > > set -x > > [ "$foo" -eq 00 ] && echo Z > [ "$foo" = 00 ] && echo Z > [ $foo -eq 00 ] && echo Z > [ $foo = 00 ] && echo Z > > foo=“0" > [ "$foo" -eq 00 ] && echo Z > [ "$foo" = 00 ] && echo Z > [ $foo -eq 00 ] && echo Z > [ $foo = 00 ] && echo Z > > foo=0 > [ "$foo" -eq 00 ] && echo Z > [ "$foo" = 00 ] && echo Z > [ $foo -eq 00 ] && echo Z > [ $foo = 00 ] && echo Z > > The unquoted expansions of $foo in the first block will lead to unknown > operand errors since $foo expands to nothing. The quoted $foo in the first > block will lead to ’sh: out of range’ because “” is not an integer suitable > for the integer -eq comparison. A solution: > > [ "$foo" ] && [ "$foo" -eq 00 ] && echo Z > > In later blocks, because $foo is now set it always expands to something so > there’s no difference between quoted vs unquoted behaviour (in this example!) > we’re just into the differences between string vs numeric value comparisons, > ie. string ‘0’ is not equal to ’00’ but value ‘0’ is equal to ’00' > > Maybe that helps. > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] (no subject)
Hello,
This is my second attempt to fix the snapshot images for D-Link DIR 860L B1.
This device accepts uncompressed uImages as initramfs only.
>From the flash it expects LZMA compressed image and ignores the uImage header.
To create a bootable image, the LZMA packed kernel prepared with the LZMA loader
has to be packed again with LZMA.
For the initramfs, it needs an LZMA compressed uImage header too.
In the second LZMA compression stage I use the fastest compression ("-a0") to
save some CPU power.
In my previous attempt the "-d18" LZMA parameter needs 128K more space,
while "-d19" and above causes LZMA ERROR 1.
With this patch (LZMA loader + double LZMA compression) it needs 64K more space,
compared to the snapshot image, which uses "-d23" as default.
--
Regards,
Szabolcs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ramips: define image recipe for plain lzma-loader for advanced cases
This change allows to make other transformations to kernel before uImage Signed-off-by: Szabolcs Hubai --- target/linux/ramips/image/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index f93ea8ab2a..707bc85f9a 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -37,9 +37,14 @@ define Device/Default IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size endef -define Device/uimage-lzma-loader +define Device/lzma-loader LOADER_TYPE := bin - KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none + KERNEL := kernel-bin | append-dtb | lzma | loader-kernel +endef + +define Device/uimage-lzma-loader + $(Device/lzma-loader) + KERNEL += | uImage none endef define Device/seama -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] ramips: mt7621: use lzma-loader for D-Link DIR-860L
This device has trouble extracting big kernel from flash,
and supports LZMA compressed kernels only.
Using OpenWrt kernel loader saves us 64 KB compared to the dictionary
size limiting workaround.
Factory image sizes (commit: 5f126c541a74) with "CONFIG_ALL_KMODS=y":
- original ("-d23", default): 4784188 bytes, LZMA ERROR 1
- with "-d19": 4915260, LZMA ERROR 1
- with "-d18": 4915260, diff to original: +128 KB
- with "-d17": 4980796, diff to original: +192 KB
- with this patch: 4849724, diff to original: +64 KB
To save some CPU cycle, use minimal compression ("-a0") for the LZMA
compressed uImage.
Signed-off-by: Szabolcs Hubai
---
target/linux/ramips/image/mt7621.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index aa6836d50a..28d2637bd3 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -216,9 +216,10 @@ TARGET_DEVICES += buffalo_wsr-600dhp
define Device/dlink_dir-860l-b1
$(Device/seama)
+ $(Device/lzma-loader)
BLOCKSIZE := 64k
SEAMA_SIGNATURE := wrgac13_dlink.2013gui_dir860lb
- KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma | uImage lzma
+ KERNEL += | relocate-kernel | lzma -a0 | uImage lzma
IMAGE_SIZE := 16064k
DEVICE_VENDOR := D-Link
DEVICE_MODEL := DIR-860L
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] toolchain/gcc: eliminate uClibc atexit hack
This seems to be over 10 years old. It doesn't seem to be needed anymore. Tested on malta with uClibc (selected BROKEN). Signed-off-by: Rosen Penev --- toolchain/gcc/common.mk | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk index 090aa2447d..7fb30285aa 100644 --- a/toolchain/gcc/common.mk +++ b/toolchain/gcc/common.mk @@ -115,7 +115,8 @@ GCC_CONFIGURE:= \ --with-mpfr=$(TOPDIR)/staging_dir/host \ --with-mpc=$(TOPDIR)/staging_dir/host \ --disable-decimal-float \ - --with-diagnostics-color=auto-if-env + --with-diagnostics-color=auto-if-env \ + --enable-__cxa_atexit ifneq ($(CONFIG_mips)$(CONFIG_mipsel),) GCC_CONFIGURE += --with-mips-plt endif @@ -150,14 +151,6 @@ ifdef CONFIG_sparc --with-long-double-128 endif -ifeq ($(LIBC),uClibc) - GCC_CONFIGURE+= \ - --disable-__cxa_atexit -else - GCC_CONFIGURE+= \ - --enable-__cxa_atexit -endif - ifneq ($(GCC_ARCH),) GCC_CONFIGURE+= --with-arch=$(GCC_ARCH) endif -- 2.25.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] sdk: add OpenWrt branding to menuconfig & .config
Set the mainmenu symbol in SDK Config.in to "OpenWrt Configuration", the same as the main OpenWrt Config.in. This string is is used as the name of the top menu in menuconfig, and at the top of the .config file. If unset, current kconfig will use "Linux Kernel Configuration". Signed-off-by: Eneas U de Queiroz diff --git a/target/sdk/files/Config.in b/target/sdk/files/Config.in index 0dab240959..4393daab5b 100644 --- a/target/sdk/files/Config.in +++ b/target/sdk/files/Config.in @@ -1,3 +1,5 @@ +mainmenu "OpenWrt Configuration" + menu "Global build settings" config ALL_NONSHARED ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] linux5.4: build-dependency to rsync
Hi, I was just building a master-branch for x86-generic and got following error: make[5]: Entering directory '/mnt/local/btrfs/build/freifunk/ffberlin/ firmware/openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ linux-5.4.28' INSTALL /mnt/local/btrfs/build/freifunk/ffberlin/firmware/openwrt/build_dir/ toolchain-i386_pentium4_gcc-8.4.0_musl/linux-dev//include /bin/sh: 1: rsync: not found make[5]: *** [Makefile:1186: headers_install] Error 127 make[5]: Leaving directory '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/linux-5.4.28' make[4]: *** [Makefile:108: /mnt/local/btrfs/build/freifunk/ffberlin/firmware/ openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ linux-5.4.28/.configured] Error 2 make[4]: Leaving directory '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ openwrt/toolchain/kernel-headers' time: toolchain/kernel-headers/compile#1.46#0.83#2.26 In https://github.com/torvalds/linux/commit/59b2bd05f5f4d the call to rsync was added. I think we have the 2 options: * use host-command (changing the build-requirements) * compile it ourself (like we do with zip: ad8c2d6099a7da51) What's the prefered way? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: add support for AVM FRITZ!WLAN Repeater 450E
SOC:Qualcomm QCA9556 (Scorpion) 560MHz MIPS74Kc
RAM:64MB Zentel A3R12E40CBF DDR2
FLASH: 16MiB Winbond W25Q128 SPI NOR
WLAN1: QCA9556 2.4 GHz 802.11b/g/n 3x3
INPUT: WPS button
LED:Power, WiFi, LAN, RSSI indicator
Serial: Header Next to Black metal shield
Pinout is 3.3V - RX - TX - GND (Square Pad is 3.3V)
The Serial setting is 115200-8-N-1.
Installation via EVA:
In the first seconds after Power is connected, the bootloader will
listen for FTP connections on 192.168.178.1. Firmware can be uploaded
like following:
ftp> quote USER adam2
ftp> quote PASS adam2
ftp> binary
ftp> debug
ftp> passive
ftp> quote MEDIA FLSH
ftp> put openwrt-sysupgrade.bin mtd1
Note that this procedure might take up to two minutes.
You need to powercycle the device afterwards to boot OpenWRT.
Tested-by: Andreas Ziegler
Signed-off-by: David Bauer
---
.../ath79/dts/qca9556_avm_fritz-repeater.dtsi | 93 +++
.../ath79/dts/qca9556_avm_fritz1750e.dts | 89 +-
.../linux/ath79/dts/qca9556_avm_fritz450e.dts | 76 +++
.../generic/base-files/etc/board.d/01_leds| 3 +-
.../generic/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 3 +-
.../base-files/lib/preinit/10_fix_eth_mac.sh | 3 +-
target/linux/ath79/image/generic.mk | 9 ++
8 files changed, 189 insertions(+), 90 deletions(-)
create mode 100644 target/linux/ath79/dts/qca9556_avm_fritz-repeater.dtsi
create mode 100644 target/linux/ath79/dts/qca9556_avm_fritz450e.dts
diff --git a/target/linux/ath79/dts/qca9556_avm_fritz-repeater.dtsi
b/target/linux/ath79/dts/qca9556_avm_fritz-repeater.dtsi
new file mode 100644
index 00..b1f5f1bdb3
--- /dev/null
+++ b/target/linux/ath79/dts/qca9556_avm_fritz-repeater.dtsi
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca9557.dtsi"
+
+/ {
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ num-cs = <1>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "urlader";
+ reg = <0x0 0x2>;
+ read-only;
+ };
+
+ partition@2 {
+ compatible = "avm,eva-firmware";
+ label = "firmware";
+ reg = <0x2 0xee>;
+ };
+
+ partition@f0 {
+ label = "tffs (1)";
+ reg = <0xf0 0x8>;
+ read-only;
+ };
+
+ partition@f8 {
+ label = "tffs (2)";
+ reg = <0xf8 0x8>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+ qca,no-eeprom;
+};
+
+ {
+ status = "okay";
+
+ phy-handle = <>;
+ pll-data = <0x300 0x101 0x1313>;
+
+ gmac-config {
+ device = <>;
+ ge0-sgmii = <0>;
+ };
+};
+
+ {
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
diff --git a/target/linux/ath79/dts/qca9556_avm_fritz1750e.dts
b/target/linux/ath79/dts/qca9556_avm_fritz1750e.dts
index f50af5b228..25d3ae8da4 100644
--- a/target/linux/ath79/dts/qca9556_avm_fritz1750e.dts
+++ b/target/linux/ath79/dts/qca9556_avm_fritz1750e.dts
@@ -1,19 +1,13 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
-/dts-v1/;
#include
-#include
-#include "qca9557.dtsi"
+#include "qca9556_avm_fritz-repeater.dtsi"
/ {
compatible = "avm,fritz1750e", "qca,qca9557";
model = "AVM FRITZ!WLAN Repeater 1750E";
- chosen {
- bootargs = "console=ttyS0,115200n8";
- };
-
aliases {
led-boot = _power;
led-failsafe = _power;
@@ -91,65 +85,14 @@
gpios = <_gpio 4 GPIO_ACTIVE_HIGH>;
};
};
-
- keys {
- compatible = "gpio-keys";
-
- wps {
- label = "wps";
-
Re: [OpenWrt-Devel] [PATCHv3] ubox: run init script through shellcheck
> On 18 Apr 2020, at 01:56, Rosen Penev wrote: > > On Fri, Apr 17, 2020 at 1:50 AM wrote: >> >>> >>> - [ $log_buffer_size -eq 0 -a $log_size -gt 0 ] && >>> log_buffer_size=$log_size >>> - [ $log_buffer_size -eq 0 ] && log_buffer_size=64 >>> + [ "$log_buffer_size" -eq 0 ] && [ "$log_size" -gt 0 ] && >> >> I'm never sure whether a comparison [ "$string" -eq 0 ], i.e. one with >> quotes and one without using -eq works as expected in all cases. >> I typically use [ "$string" = "0" ] instead, but I'm not sure whether that's >> effectively just the same. > Sounds bogus. log_buffer_size and log_size are stated to be uintegers above. >> >> Rest seems fine, despite some similar cases with -eq/-ne below. > -eq/-ne vs = is a stylistic difference. I disagree. ‘= != < >’ are string comparisons, -eq/-ne/gt/lt/ge/le are numeric/arithmetic comparisons. Consider this slightly contrived case where to emphasise the difference between string and numeric comparison I compare to ’00’ which is arithmetically zero, but not just a simple, lone ‘0’ string. #!/bin/sh set -x [ "$foo" -eq 00 ] && echo Z [ "$foo" = 00 ] && echo Z [ $foo -eq 00 ] && echo Z [ $foo = 00 ] && echo Z foo=“0" [ "$foo" -eq 00 ] && echo Z [ "$foo" = 00 ] && echo Z [ $foo -eq 00 ] && echo Z [ $foo = 00 ] && echo Z foo=0 [ "$foo" -eq 00 ] && echo Z [ "$foo" = 00 ] && echo Z [ $foo -eq 00 ] && echo Z [ $foo = 00 ] && echo Z The unquoted expansions of $foo in the first block will lead to unknown operand errors since $foo expands to nothing. The quoted $foo in the first block will lead to ’sh: out of range’ because “” is not an integer suitable for the integer -eq comparison. A solution: [ "$foo" ] && [ "$foo" -eq 00 ] && echo Z In later blocks, because $foo is now set it always expands to something so there’s no difference between quoted vs unquoted behaviour (in this example!) we’re just into the differences between string vs numeric value comparisons, ie. string ‘0’ is not equal to ’00’ but value ‘0’ is equal to ’00' Maybe that helps. signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
