Re: [PATCH v2 1/2] modutils: check ELF header before calling finit_module()
On Tue, 5 Jan 2021 10:47:25 +0800 Kang-Che Sung wrote: > I don't see why the > "Invalid ELF header" message would bother you so much, since you > won't load kernel modules often. As mentioned in my original post, it's a pr_err. It shows up on console! So every boot there's 20 scary errors interspersed with boot messages. No need for the curious to see if dmesg was spammed, it's in their face. - Lauri ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2 1/2] modutils: check ELF header before calling finit_module()
On Mon, Jan 4, 2021 at 6:32 PM Qu Wenruo wrote: > > On 2021/1/4 下午6:01, Kang-Che Sung wrote: > > On Sun, Jan 3, 2021 at 12:11 PM Qu Wenruo wrote: > >> > >> finit_module() and init_module() system calls have clear specification > >> to only accept valid ELF image. > >> > >> Although we try finit_module() on compressed modules to let the kernel > >> determine if it's an ELF image, but it's not ideal, especially when > >> newer kernel will complain when some invalid files/memory is passed in. > >> > >> Treat the kernel better by just doing a very basic ELF header check > >> before calling finit_module(). > >> > >> Signed-off-by: Qu Wenruo > > > > What is the reason for not letting the kernel do all the ELF sanity checks? > > Performance? Security? For now this looks like extra code to busybox > > without obvious benefits. > > > To avoid possible "Invalid ELF header" error message from kernel. > > Since those system calls are only to accept ELF header, kernel has its > right to info the caller that it got some invalid ELF header (even if > it's just compressed file). > > Or did you mean, busybox pursues size so much that it doesn't matter to > not follow system call spec? It is normal for the kernel to receive a malformed ELF file through init_module() and it's the kernel's job to reject it. I don't see why the "Invalid ELF header" message would bother you so much, since you won't load kernel modules often. By "security" I mean, if the kernel would accept any header other than ELF and you want to ensure only ELF is passed to the system call, then it's fine to add that sanity check. Otherwise, there's no benefit for repeating what the kernel would do in busybox. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix for the FEATURE_UTMP on the FreeBSD
Applied, thank you. On Mon, Jan 4, 2021 at 7:35 PM Alex Samorukov wrote: > > FreeBSD is not using and does not define _PATH_UTMPX. > Tested with busybox applets depending on FEATURE_UTMP (e.g. who, users, etc) > > Signed-off-by: Alex Samorukov > --- > include/libbb.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/include/libbb.h b/include/libbb.h > index dad6fc687..664bf0410 100644 > --- a/include/libbb.h > +++ b/include/libbb.h > @@ -106,7 +106,11 @@ > # define updwtmpx updwtmp > # define _PATH_UTMPX _PATH_UTMP > # else > +#ifndef __FreeBSD__ > # include > +#else > +#define _PATH_UTMPX "/var/run/utx.active" > +#endif > # include > # if defined _PATH_UTMP && !defined _PATH_UTMPX > # define _PATH_UTMPX _PATH_UTMP > -- > 2.29.1 > > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: AW: [PATCH] ash: Load $ENV file also if $SSH_CLIENT/SSH2_CLIENT is preset in env, reformat
On Mon, Jan 4, 2021 at 8:48 PM Björn Bidar wrote:
> Am Montag, 4. Januar 2021, 14:43:46 EET schrieben Sie:
> > > > Please explain your real-world scenario which prompted you
> > > > to create the patch.
> > >
> > > The real world scenario is that a user might run commands via ssh on a
> > > device using busybox ash but expect a certain set of environment
> > > variables present or run some scripts that set up the shell session.
> >
> > I meant: what was _your_ real-world scenario which prompted you to create
> > the patch. You had $ENV set up? Where it was set from - /etc/profile?
> > ~/.profile?
> > It was doing which important setup? Why moving this setup to .profile
> > was not feasible? etc...
> Profile is not sourced in an non interactive session eg. Ssh foobar bar
>
> I explained my real world scenario already a developer running a common to a
> device via ssh and needing to have that environment setup.
>
> I set the Env Variable in sshd_config but it could be setup anywhere eg. to
> emulate an rc file.
Thank you.
I don't think we should address it this way.
What bash does is essentially an undocumented hack ("if run by SSH,
make my shell
a little bit like interactive one, but not really), albeit the hack is useful
enough to be adopted.
The same rationale says ash users will also want this hack. Okay.
But what you propose is not exactly the same hack. It's a slightly
different one:
it executes "$ENV", not .bashrc. If we'd do this, now bash and ash
will have two subtly different hacks. When run from ssh, bash -c "CMD"
will run .bashrc, but not "$ENV". ash will run "$ENV", but not .[b]ashrc
Care to just add functionality to ash to have .ashrc startup file, with the same
rules as bash has for .bashrc?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Nuke
On Mon, Jan 4, 2021 at 5:43 PM Tim Tassonis wrote: > On 1/3/21 4:31 PM, Denys Vlasenko wrote: > > On Sun, Jun 21, 2020 at 4:56 AM Eli Schwartz > > wrote: > >> On 6/20/20 7:26 AM, Mike Davies wrote: > >>> So whos brilliant idea was it to select 'nuke' to be built by default ? > > > > Almost all options are "on" by default. > > There should be a special reason (documented in a comment) > > why option is off by default (e.g. "non-standard behavior" > > or "some common libc don't have necessary defines / functions > > to compile it"). > > > > Just a quick question in general: why is this applet needed anyway, and > where does it come from? klibc-utils ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: AW: [PATCH] ash: Load $ENV file also if $SSH_CLIENT/SSH2_CLIENT is preset in env, reformat
Am Montag, 4. Januar 2021, 14:43:46 EET schrieben Sie: > On Sun, Jan 3, 2021 at 6:25 PM Björn Bidar wrote: > > Am Sonntag, 3. Januar 2021, 11:43:25 EET schrieben Sie: > > > I can see that ash users also might need their init scripts to be run > > > for "ssh USER@HOST COMMAND", but ash has no .bashrc analogue as of now. > > > Your code does not reproduce bash behavior - bash does NOT run $ENV > > > script, it runs .bashrc script for ssh (see above). > > > > I know that, that is why I said it emulates a behaviour. > > > > > IOW - the patch adds a special-case for ssh which is *different* > > > from bash. > > > > > > Please explain your real-world scenario which prompted you > > > to create the patch. > > > > The real world scenario is that a user might run commands via ssh on a > > device using busybox ash but expect a certain set of environment > > variables present or run some scripts that set up the shell session. > > I meant: what was _your_ real-world scenario which prompted you to create > the patch. You had $ENV set up? Where it was set from - /etc/profile? > ~/.profile? > It was doing which important setup? Why moving this setup to .profile > was not feasible? etc... Profile is not sourced in an non interactive session eg. Ssh foobar bar I explained my real world scenario already a developer running a common to a device via ssh and needing to have that environment setup. I set the Env Variable in sshd_config but it could be setup anywhere eg. to emulate an rc file. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] Fix for the FEATURE_UTMP on the FreeBSD
FreeBSD is not using and does not define _PATH_UTMPX. Tested with busybox applets depending on FEATURE_UTMP (e.g. who, users, etc) Signed-off-by: Alex Samorukov --- include/libbb.h | 4 1 file changed, 4 insertions(+) diff --git a/include/libbb.h b/include/libbb.h index dad6fc687..664bf0410 100644 --- a/include/libbb.h +++ b/include/libbb.h @@ -106,7 +106,11 @@ # define updwtmpx updwtmp # define _PATH_UTMPX _PATH_UTMP # else +#ifndef __FreeBSD__ # include +#else +#define _PATH_UTMPX "/var/run/utx.active" +#endif # include # if defined _PATH_UTMP && !defined _PATH_UTMPX # define _PATH_UTMPX _PATH_UTMP -- 2.29.1 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix traceroute applet on the FreeBSD
On 04.01.2021 12:35, Denys Vlasenko wrote: > Applied 10 patches. Thank you. > Thank you! I will send one more patch today. P.S. I did a wiki page [1] about current status, will try to keep it up to date. https://github.com/samm-git/busybox/wiki ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Nuke
On 1/3/21 4:31 PM, Denys Vlasenko wrote: On Sun, Jun 21, 2020 at 4:56 AM Eli Schwartz wrote: On 6/20/20 7:26 AM, Mike Davies wrote: So whos brilliant idea was it to select 'nuke' to be built by default ? Almost all options are "on" by default. There should be a special reason (documented in a comment) why option is off by default (e.g. "non-standard behavior" or "some common libc don't have necessary defines / functions to compile it"). Just a quick question in general: why is this applet needed anyway, and where does it come from? It does not seem to be part of any sane linux distribution I've ever heard and I don't really see any point in it. If someone for any strange reason really needs a shortcut to "\rm -rf /", he might set an alias. I'm quite sure 99% of busybox users have no use for it. Bye Tim ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2 1/2] modutils: check ELF header before calling finit_module()
On 2021/1/4 下午6:01, Kang-Che Sung wrote: On Sun, Jan 3, 2021 at 12:11 PM Qu Wenruo wrote: finit_module() and init_module() system calls have clear specification to only accept valid ELF image. Although we try finit_module() on compressed modules to let the kernel determine if it's an ELF image, but it's not ideal, especially when newer kernel will complain when some invalid files/memory is passed in. Treat the kernel better by just doing a very basic ELF header check before calling finit_module(). Signed-off-by: Qu Wenruo What is the reason for not letting the kernel do all the ELF sanity checks? Performance? Security? For now this looks like extra code to busybox without obvious benefits. To avoid possible "Invalid ELF header" error message from kernel. Since those system calls are only to accept ELF header, kernel has its right to info the caller that it got some invalid ELF header (even if it's just compressed file). Or did you mean, busybox pursues size so much that it doesn't matter to not follow system call spec? Thanks, Qu ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix traceroute applet on the FreeBSD
Applied 10 patches. Thank you.
On Mon, Jan 4, 2021 at 1:41 AM Alex Samorukov wrote:
>
> This patch addressing 2 issues:
>
> 1. Replacing source/dest with uh_sport/uh_dport. It seems that uh_* members
> are
>defined on both Linux and BSD, so no #ifdef here
> 2. Use SOL_IPV6 instead of SOL_RAW on the FreeBSD to fix IPV6_CHECKSUM
> setsockopt
>
> Signed-off-by: Alex Samorukov
> ---
> networking/traceroute.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/networking/traceroute.c b/networking/traceroute.c
> index bd63e4449..7cba9d2f1 100644
> --- a/networking/traceroute.c
> +++ b/networking/traceroute.c
> @@ -716,8 +716,8 @@ packet4_ok(int read_len, int seq)
> // Off: since we do not form the entire IP packet,
> // but defer it to kernel, we can't set source port,
> // and thus can't check it here in the reply
> - /* && up->source == ident */
> -&& up->dest == htons(port + seq)
> + /* && up->uh_sport == ident */
> +&& up->uh_dport == htons(port + seq)
> ) {
> return (type == ICMP_TIMXCEED ? -1 : code +
> 1);
> }
> @@ -985,8 +985,13 @@ traceroute_init(int op, char **argv)
> snd = xsocket(AF_INET, SOCK_DGRAM, 0);
> }
> #if ENABLE_TRACEROUTE6
> +#ifdef __FreeBSD__
> +#define SOL_V6_OPTION SOL_IPV6
> +#else
> +#define SOL_V6_OPTION SOL_RAW
> +#endif
> else {
> - if (setsockopt_int(rcvsock, SOL_RAW, IPV6_CHECKSUM,
> 2) != 0)
> + if (setsockopt_int(rcvsock, SOL_V6_OPTION,
> IPV6_CHECKSUM, 2) != 0)
> bb_perror_msg_and_die("setsockopt(%s)",
> "IPV6_CHECKSUM");
> if (op & OPT_USE_ICMP)
> snd = xsocket(AF_INET6, SOCK_RAW,
> IPPROTO_ICMPV6);
> --
> 2.29.1
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2 1/2] modutils: check ELF header before calling finit_module()
On Sun, Jan 3, 2021 at 12:11 PM Qu Wenruo wrote: > > finit_module() and init_module() system calls have clear specification > to only accept valid ELF image. > > Although we try finit_module() on compressed modules to let the kernel > determine if it's an ELF image, but it's not ideal, especially when > newer kernel will complain when some invalid files/memory is passed in. > > Treat the kernel better by just doing a very basic ELF header check > before calling finit_module(). > > Signed-off-by: Qu Wenruo What is the reason for not letting the kernel do all the ELF sanity checks? Performance? Security? For now this looks like extra code to busybox without obvious benefits. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
