This one shows a separate dnsmasq instance with its own config file suffixes (not belonging to the main dnsmasq instance).
Can the 'tag' or other functionality in the UCI system be leveraged in some way like:
root@OpenWrt-1:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option cachesize '1000'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option ednspacket_max '1232'
option filter_aaaa '0'
option filter_a '0'
list server '127.0.0.1#5453'
list server '0::1#5453'
XXX
config dnsmasq 'adblock_lean'
list addnmount '/bin/busybox'
Such that we can then just delete the dnsmasq adblock-lean 'section', if you will.
The specific form in the example above isn't working for some reason.
As an alternative @antonk, if comments inside /etc/config files are supported, then can't we just append a comment with #adblock-lean and leverage that when removing the entry to distinguish over any user-added entries?
No, it was never going to work. These are procd ujail options, not dnsmasq options, so not as forgiving. I don’t see any reason to expect other users to be mounting busybox in the dnsmasq jail, because as we discussed a long while back, having busybox in the jail rather defeats the purpose of the jail.
It should be fine to just delete the busybox entry from the list of addnmount options on uninstall.
I see it now, your ps output was also the separate dnsmasq instance since the main instance failed to startup. Harder to see with the non-wrapping output,
I compared the complete command lines and they are identical.
How can you tell it's not the "main" dnsmasq instance?
The main instance files will use the cfg01411c suffix (representing the unnamed @dnsmasq[0] section of the config).
How about just simple comment #adblock-lean to achieve same functionality @antonk? Delete the entry conditional on it including the appended comment #adblock-lean?
config dnsmasq
xxx
list addnmount '/bin/busybox' #adblock-lean
Custom comments are not preserved on automatic config updates (I believe I read this in the UCI manual), so this won't work. But maybe we can append the comment to the command line - I'll test.
^ This seems to work. Implemented in current revision - please test.
1 Like
Yes worked for me!
What's the order of precedence again for && and ||? I'm thinking of this portion:
while uci -q get dhcp.@dnsmasq[${i}] >/dev/null && [ ${i} -lt 128 ]
do
i=$((i+1))
entry="$(uci -q get dhcp.@dnsmasq[${i}].addnmount)" || continue
case "${entry}" in *adblock-lean*) ;; *) continue; esac
log_msg -purple "" "Deleting the custom addnmount entry from /etc/config/dhcp."
uci -q del_list dhcp.@dnsmasq[${i}].addnmount='/bin/busybox # adblock-lean' && uci commit ||
reg_failure "Failed to delete the custom addnmount entry from /etc/config/dhcp. Please delete manually."
break
done
Will the reg_failure kick in if either the del_list or commit fails?
Yes. Given this:
[ a ] && [ b ] || c
c will be evaluated if either [ a ] or [ b ] doesn't return 0.
1 Like
Can you repost the ps output? Curious to see how or if the comment affects the ujail command line parameters.
2 Likes
root@OpenWrt-1:~# pgrep -af ujail | grep dnsmasq
18971 /sbin/ujail -t 5 -n dnsmasq -u -l -r # -r /bin/busybox -r /bin/ubus -r /etc/TZ -r /etc/dnsmasq.conf -r /etc/ethers -r /etc/group -r /etc/hosts -r /etc/passwd -w /tmp/dhcp.leases -r /tmp/dnsmasq.d -r /tmp/hosts -r /tmp/resolv.conf.d -r /usr/bin/jshn -r /usr/lib/dnsmasq/dhcp-script.sh -r /usr/share/dnsmasq/dhcpbogushostname.conf -r /usr/share/dnsmasq/rfc6761.conf -r /usr/share/dnsmasq/trust-anchors.conf -r /usr/share/libubox/jshn.sh -r /var/etc/dnsmasq.conf.cfg01411c -w /var/run/dnsmasq/ -r adblock-lean -- /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
So -r # ? Problem or not?
It’s also adding adblock-lean further to the right.
So it’s not an inert comment.
1 Like
Yeah, unfortunately this won't cut it. I'm out of ideas.
The 4 options I see from here for uninstalling are:
- Remove the addnmount entry quietly (may break other software if it's using that)
- Same but print a note in the console that the entry is removed, and there is a small chance that this breaks other software
- Leave the addnmount entry in place (has potential security implications which we can't really assess)
- Ask the user (may pose a challenge for the user to figure out what to answer)
What do you guys prefer? I kinda tend towards (2).
1 Like
#1 gets my vote. Only 1 other package manipulates addnmount (cache-domains) and it’s not adding or removing busybox.
It’s only useful for scripts being spawned by the jailed dnsmasq daemon (e.g. conf-script or dhcp-script). Very low risk of high adoption at this point in time by individuals writing their own scripts.
Yeah also #2, but worded in a way so as not to cause any alarm!
By the way @dave14305, I forget how poking through the jail sufficiently that we can properly leverage the prisoner held within actually works in this situation.
Can we not in some way restrict to a specific busybox command say by having an executable script that calls gunzip or some other means?
Implemented in current revision. How's the wording?
(you may need to delete existing experimental addnmount entry and then run setup again, otherwise entry removal may fail)
How about:
Note: the adblock-lean developers are not aware of any other software that requires the specific addnmount entry created by adblock-lean. Should the addnmount entry be required for any reason then you will need to manually re-add the addnmount entry.
1 Like