This calls striptags() on the hostname to prevent any XSS over the
hostname. This should fix CVE-2021-33425 as far as I understood it.
If someone adds some Javascript into system.@system[0].hostname it would
have been directly added to the page, this prevents the problem.
This can only be exploited by someone being able to modify the uci
configuration, normally a user with such privileges could also just
modify the webpage.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 5cbd79d7e31c0f0feaea2770bf102bbae7831e3c)
When including luci.mk in external repos it's sometimes usefull to not use
the default LuCI-submenu hierarchy.
This change defines the LUCI_SUBMENU_FORCED variable which completely overrides
the default submenu of the LuCI config-section. When LUCI_SUBMENU_FORCED is not
defined, the default submenu derrived from LUCI_TYPE or "Application" fallback
is used.
Defining LUCI_SUBMENU_FORCED in the package Makefile will just use this value.
Setting it to "none" will not define a submenu at all.
Together with LUCI_SECTION and LUCI_CATEGORY menu items can now created at any
place in the menu structure.
Signed-off-by: Sven Roederer <devel-sven@geroedel.de>
(cherry picked from commit 2b11ec6fd02be060443cf4afc9d89058aadcfab3)
Add PKG_PROVIDES macro to be passed down to buildpackage defines as PROVIDES variable.
Signed-off-by: Sven Roederer <devel-sven@geroedel.de>
(cherry picked from commit 209141d49153b999c42b0410010366789b36e86d)
Add the LUCI_URL and LUCI_MAINTAINER variables to pass them to the buildpackage
defines. Give them some sane defaults and allow overwritting by the individual
package.
Signed-off-by: Sven Roederer <devel-sven@geroedel.de>
(cherry picked from commit ae0795deb0c908515550236254b04334be8f90bf)
Since `uci.get()` may return null or array values, we cannot blindly call
split() on the result. Use the safe `L.toArray()` helper which is intended
to deal with such situations.
Also clean up whitespace while we're at.
Fixes: #5080
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit c4cdfcbe5121d5959dac1e18ed11b8611a86fb9e)
Problem with handling all migrations in 1 step is that uci.sections()
doesn't include changes queued using uci.callAdd() and uci.callSet().
That could result in unexpected behaviour and generating invalid
configs.
For the sake of simplicity and reliability use 2 steps migration. The
downside is that users may get prompted twice to migrate.
Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
Fixes: 74be304e541f ("treewide: use "device" option in UCI "interface" sections")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Tested-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit e7c9c63c657963daa1a0d57dcb0848d88e909c25)
Those are L2 options that are not part of interfaces (L3), should not be
set there and don't work. Setting MAC and MTU should be done at device
layer (config device) and is supported for basic types already.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 79947af064122438c803f3b7bc580ede093a26e4)
The introduction of network device configuration support also implemented
all common, protocol-independent interface options directly in the
interface config view, so drop the redundant option definitions.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 171ef77e8985ffd90eb66b8a0a3cd74beb37ccdc)
Using "device" option requires netifd from 2021-05-26 or newer.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit bc81e09781de229e85ad74afd785afdd454b4892)
netifd has been recently patched to use "device" option instead of
"ifname" as more clear & accurate.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 74be304e541f5c03dacbdb05c543dfa6f79205a6)
Checking netifd version is important for users of the most recent LuCI
that didn't update netifd (e.g. OpenWrt package).
Suggested-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 17af33ee48bb709aec31d09b90cfbd4cbece6d0d)
LuCI supports only the newer method of specifying bridge ports using the
"ports" option. Offer users migration so they can configure their
network.
Example:
1. Before
config device
option name 'br-lan'
option type 'bridge'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'
2. After
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit b8acde7f480a18343ee1f9624b790595065613ae)
Device ("ifname" UCI option) doesn't depend on protocol so there is no
need to hide / reset it on protocol change.
While at it drop names of two removed inputs (dead code).
Fixes: ec020cee0c44 ("luci-mod-network: drop support for *editing* legacy bridges")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 907b4222f70b3351d590d8a2e35c21a4ae07db8d)
LuCI now supports the updated UCI syntax for bridges that requires:
1. device section for L2
2. interface section for L3
Check for legacy syntax usage and offser user a migration to allow
changing network config.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit bca76a767316a689d59dfd4974dcb7bfb04db1e8)
netifd has been recently patched to use more accurate "ports" option
instead of "ifname"
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit a90115cd82372eaaa0ed531800b568387e200c97)
The old way of defining bridge (L2) as part of interface (L3) is
deprecated. All such configs should be migrated to define bridge as L3
UCI section type "device".
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit ec020cee0c44793f8ce1b346675c6a36e63b0154)
The old way of defining bridge (L2) as part of interface (L3) is
deprecated. Don't support *adding* interfaces like that.
Support for *editing* legacy bridges is kept for now for compatibility
with existing legacy setups.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit b7f3cf66cadf6753153bc9d1feac1eca0c7e37f0)
Ensure that device sections are only automatically removed after all
related options have been parsed, to avoid prematurely deleting sections.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 2072c66c5a4b755a6ed16bb6486afb956a475be9)
Introduce a `migrate` properties which selectively allows disabling the
`config interface` to `config device` migration logic for single options.
Use the new flag to disable migration of the "ipv6" option which has
different semantics in interface and device sections.
Ref: https://forum.openwrt.org/t/pppoe-disable-ipv6/92548
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 935e9a3c3430db5fad1004926ddfa2e35a950be5)
Only disable legacy bridging if an existing network.device section with type
bridge is found, ignore non-type sections since those do not declare a
bridge but set attributes on top of an existing one.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit f48f9f11e7f6e3d74e2fd4b6b2478e5673f2f459)
The existing logic only handled removing the last remaining device section
option (which results in the deletion of the entire section) but failed to
actually unset single options.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit b9fad85f2e3fc988528fd326db715719288604ea)
When setting bridge and device specific options such 'stp' or
'igmp_snooping', LuCI so far transparently created or reused a
`config device` section and set the corresponding option there.
In the case of bridges, this triggers multiple problems:
- When implicitely creating a `config device` section referring to the
bridge device, the legacy bridge configuration of the corresponding
interface is disabled, causing a broken configuration on subsequent
save operations
- Netifd does not appear to properly merge bridge settings from config
device and config interface sections, leading to an incoherent
configuration state
In order to avoid that issue, do not automatically migrate bridge specific
options.
Fixes: #4948
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit a9a223b973c7f5f057d19a7fc09e7364087fec79)
The previous change didn't take dynamic dependency mangling into account.
Fixes: 2bfd4908a9 ("luci-mod-network: restore DNS option semantics for proto static")
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 9a92f9c7615f710a7934cccc8ac23902247c154b)
The peerdns settings makes little practical sense for proto:static
interfaces, so revert to allow setting the DNS server list directly.
Fixes: faad7464a8 ("luci-mod-network: add support for network.device sections")
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 2bfd4908a9cfeac74c7abc31d8cef0bf1e58af52)
- Disable interface-level bridging if a corresponding br-$name bridge
already exists as device declaration
- Exempt wireless interfaces from bridge port configuration, they can only
be attached indirectly through "option network"
- Consider bridge ports from both "option ifname" in interface/device
sections and from "option ports" in bridge-vlan ones
- Small fixes for rendering quirks
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 14fdce0fcdfe39ff4143b294a1f1f65d7c783ce7)
Recent netifd automatically adds wireless devices as bridge ports if the
layer 2 device referenced by the "config interface" target network is a
Linux network bridge or a VLAN interface on top of a network bridge.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 3b4c161e01e2bd19105c123fbec463bc069d637b)
Use the newly introduced devtype attribute for more robust network device
type detection. This also allows us to easily recognize DSA ports.
Furthermore, synthesize VLAN devices declared by uci bridge-vlan sections,
similar to how it is done for legacy swconfig switch_vlan ones.
Finally implement a new Network.Device.getParent() method to use the newly
available "parent" attribute to resolve the base device of DSA ports or
VLAN devices.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit d1bf56d7f178f1b7582d7b3600ee70e65128ccfa)
Before this commit, assigning the same static IP address to two
different hosts disabled dnsmasq.
Logic of adding a new static lease was modified. If user try to assign a
new MAC address to already reserved IP, old lease will be modified (list
of MAC addresses will be extended by new MAC) instead of creation a new lease with the same IP.
Signed-off-by: Oleksandr Pastushkov <oleks.pastushkov@gmail.com>
(cherry picked from commit 463e910119813aaea0755ff5c16c91ce412a8cbb)
It got accidentally added while cherry picking RA and NDP params
support.
Fixes: 3a9ebc537f63 ("luci-mod-network: Introduce new RA and NDP params with help-text.")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Before fixed, if we have two nodes: 'services/ddns' and 'services/ddnsto',
click any one of they, will show they all actived.
Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
(cherry picked from commit 97d50d2c6b80805cd7e513eeafc8b62fef4ab1b6)
