Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?

[Sam Liddicott]

This is also a problem with many virtual appliances. There is no easy
answer to this kernel bootup entropy problem and it is lamentable that
solutions are delegated to user space, and even to scripts, and to
non-experts who will do a bad job of it but not know it.

You may as well feed what random data you have into rngd which will supply
it to the kernel. You may as well feed /dev/urandom back, as has been
pointed out, it is well-hashed (though then stretched) original entropy.
It's a very poor solution but if there was a good solution it would be
built into the kernel. (I remember the days when random state was saved on
shutdown to be re-used on bootup).

If you have control over the hardware spec, get a good random device
on-board, RPMB or a TPM or something that can produce real random data on
demand and provides /dev/hwrng against which you can run rngd to keep
entropy full.

My particular advice is to not simply dump some limited amount of poor
"entropy" into the pool, because in corner cases (especially if retry is
needed) it may not always be enough for whatever early processes need it.
Instead, use rngd to keep the pool full enough until you get past this
stage and then kill rngd. Having poor entropy is bad enough, but stalling
boot because you don't have enough poor entropy because you guessed wrong...

Some processes unexpectedly consume entropy, e.g. openssl has been seen to
consume entropy even when decrypting. If you decrypt enough things you can
stall on entropy starvation.

Sam

On Tue, 19 Sept 2023 at 07:12, Michael Conrad 
wrote:

> On 9/19/23 01:36, Roberto A. Foglietta wrote:
>
> On Tue, 19 Sept 2023 at 03:25, Michael Conrad 
> wrote:
>
>> On 9/18/23 06:14, Guillermo Rodriguez Garcia wrote:
>>
>> everything is compressed with gzip -7. This is the worst scenario.
>>> However, even in the worst scenario due to gzip one single bit of
>>> difference in the input generates a completely different compressed
>>> output:
>>>
>>
>> Compression (or any other deterministic manipulation of data) does not
>> add any entropy (or "unpredictability") since the processing is 100%
>> reproducible.
>> In terms of entropy the output of the function is as good (or as bad) as
>> the amount of entropy in the initial seed.
>>
>> Hi Michel,
>
>> Even aside from that, using gzip as some sort of hash function is not
>> going to be anywhere near as good as using an actual hash function, like
>> sha256, sha1 or even md5.
>>
>
> PREMISE
>
> Hashing functions and compression algorithms are two completely different
> kinds of mathematical tools. The most obvious difference is that
>
> That's a very large response so I'm not sure which part to quote, but I
> think you're still missing the point.  Assuming your initialization of
> randomness is meant to stop people from guessing the RSA/SSL keys you
> generate on a small low-power device during startup scripts, the attacker
> will probably have a copy of your device and be able to replay any of the
> steps you take during your startup script.  It will not matter whether you
> took a few random bits and a large static text and ran it through pigz
> before feeding it to /dev/urandom, because the attacker will start with
> guesses of the same few bits and also run them and that same static text
> through pigz to potentially get the same output.  If they mirror your
> initialization of /dev/urandom, then they can try to guess your RSA keys.
> The only defense is having more actual bits of entropy, or preserving them
> from a previous boot in a manner that the attacker can't read.
>
> My comment about hashing functions was implying that they would be used
> repeatedly, not that the entire input would be condensed into one single
> hash.  Yes there is a reduction of entropy if you feed a hash function more
> than 20 bytes of data and only get 20 out of it.  My point was that no
> hashing or compression is needed, because the kernel RNG is itself a sort
> of hash function and should handle that.  Just feed it the raw input bytes.
>
> -Mike
> ___
> 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] Re: SIGPIPE and tee

[Sam Liddicott]

Thanks - that change is great. Busybox tee now propagates SIGPIPE just like
GNU tee does by default.

Sam



On Mon, 7 Oct 2019 at 13:27, Denys Vlasenko 
wrote:

> On Fri, Oct 4, 2019 at 11:20 AM Sam Liddicott  wrote:
> > nudge on this attached patch
> >
> > -- Forwarded message -----
> > From: Sam Liddicott 
> > Date: Fri, 13 Sep 2019 at 11:15
> > Subject: Re: SIGPIPE and tee
> > To: busybox 
> >
> >
> > Here is a patch which invokes kill_myself_with_sig(SIGPIPE) if fwrite
> fails with errno=EPIPE.
> >
> > Quitting with a signal rather than a diagnostic output emulates GNU tee
> which is in line with the apparent reason for busybox tee in ignoring
> SIGPIPE in the first place.
>
>
> >
> > I have tested it with and without CONFIG_FEATURE_TEE_USE_BLOCK_IO=y
> >
> > As expected, dd succeeds for bs=1024 with
> CONFIG_FEATURE_TEE_USE_BLOCK_IO=y but fails for without.
> > dd fails in both cases for bs=1024000
> > tee fails in both cases
> >
> > ( sleep 2 ; dd if=/dev/zero bs=1024000 count=5 ; echo dd $? > /dev/tty ;
> ) | {
> build_output/sysroots-components/x86_64/busybox-native/bin/busybox.nosuid
> tee /dev/null ; echo tee $? >/dev/tty ; } | sleep 1
> >
> > ( sleep 2 ; dd if=/dev/zero bs=1024 count=5 ; echo dd $? > /dev/tty ; )
> | {
> build_output/sysroots-components/x86_64/busybox-native/bin/busybox.nosuid
> tee /dev/null ; echo tee $? >/dev/tty ; } | sleep 1
> >
> > A colleague has suggested that any write failure to stdout by tee ought
> to cause tee to quit, but I leave this to your consideration; something
> like this might cover both cases but I haven't tested it:
> >
> > if (fwrite(buf, 1, c, *fp) != c) {
> >   if (errno == EPIPE) kill_myself_with_sig(SIGPIPE);
> >   retval = EXIT_FAILURE;
> >   break;
> > }
> >
> > Sam
> >
> >
> > On Thu, 12 Sep 2019 at 20:03, Sam Liddicott  wrote:
> >>
> >> In  https://git.busybox.net/busybox/tree/coreutils/tee.c we read:
> >>
> >> /* gnu tee ignores SIGPIPE in case one of the output files is a pipe
> >> * that doesn't consume all its input.  Good idea... */
> >> signal(SIGPIPE, SIG_IGN);
> >>
> >>
> >> Sadly, this breaks POSIX SIGPIPE behaviour with respect to quitting
> when stdout (as a pipe) is closed.
> >>
> >> Despite the comment, GNU tee does not behave as the comment suggests.
>
> Exactly. GNU tee does not intercept SIGPIPE (unless -p is given).
> I'm removing SIGPIPE handling.
> Please try current git.
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[PATCH] Re: SIGPIPE and tee

[Sam Liddicott]

nudge on this attached patch

-- Forwarded message -
From: Sam Liddicott 
Date: Fri, 13 Sep 2019 at 11:15
Subject: Re: SIGPIPE and tee
To: busybox 


Here is a patch which invokes kill_myself_with_sig(SIGPIPE) if fwrite fails
with errno=EPIPE.

Quitting with a signal rather than a diagnostic output emulates GNU tee
which is in line with the apparent reason for busybox tee in ignoring
SIGPIPE in the first place.

I have tested it with and without CONFIG_FEATURE_TEE_USE_BLOCK_IO=y

As expected, dd succeeds for bs=1024 with CONFIG_FEATURE_TEE_USE_BLOCK_IO=y
but fails for without.
dd fails in both cases for bs=1024000
tee fails in both cases

( sleep 2 ; dd if=/dev/zero bs=1024000 count=5 ; echo dd $? > /dev/tty ; )
| {
build_output/sysroots-components/x86_64/busybox-native/bin/busybox.nosuid
tee /dev/null ; echo tee $? >/dev/tty ; } | sleep 1

( sleep 2 ; dd if=/dev/zero bs=1024 count=5 ; echo dd $? > /dev/tty ; ) | {
build_output/sysroots-components/x86_64/busybox-native/bin/busybox.nosuid
tee /dev/null ; echo tee $? >/dev/tty ; } | sleep 1

A colleague has suggested that *any* write failure to *stdout* by tee ought
to cause tee to quit, but I leave this to your consideration; something
like this *might* cover both cases but I haven't tested it:

if (fwrite(buf, 1, c, *fp) != c) {
  if (errno == EPIPE) kill_myself_with_sig(SIGPIPE);
  retval = EXIT_FAILURE;
  break;
}

Sam


On Thu, 12 Sep 2019 at 20:03, Sam Liddicott  wrote:

> In  https://git.busybox.net/busybox/tree/coreutils/tee.c we read:
>
>   /* gnu tee ignores SIGPIPE in case one of the output files is a pipe
>  * that doesn't consume all its input.  Good idea... */
>   signal(SIGPIPE, SIG_IGN);
>
>
> Sadly, this breaks POSIX SIGPIPE behaviour with respect to quitting when
> stdout (as a pipe) is closed.
>
> Despite the comment, GNU tee does not behave as the comment suggests.
>
> Comparing 1.27.2-2ubuntu3.2 with tee (GNU coreutils) 8.28
>
> I test with one output file and stdout that stops early causing SIGPIPE
>
> 1. GNU tee
>
> ( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( tee
> /dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null
>
> 10+0 records in
> 10+0 records out
> 100 bytes copied, 0.000387276 s, 258 kB/s
> tee 141
> done 141
>
> the first two pipeline stages have exit code 141 due to sigpipe as we
> would expect
>
> 2. busybox tee
>
> ( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( busybox tee
> /dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null
> 10+0 records in
> 10+0 records out
> 100 bytes copied, 0.000291134 s, 343 kB/s
> 8192+0 records in
> 8192+0 records out
> 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0447136 s, 188 MB/s
> done 0
> tee 0
>
> both prior pipeline elements have exit code zero and the first stage
> processed all of the data
>
> The POSIX spec for tee reads:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tee.html
> CONSEQUENCES OF ERRORS
>
> If a write to any successfully opened *file* operand fails, writes to
> other successfully opened *file* operands and standard output shall
> continue, but the exit status shall be non-zero. Otherwise, the default
> actions specified in *Utility Description Defaults*
> <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04>
>  apply.
>
> But this case deals with a failure to write to stdout, not a failure to
> write to a *file* operand.
>
> Certainly, with this behaviour, busybox tee does not comply with GNU tee
> as it appears to intend, so I suggest that the line signal(SIGPIPE,
> SIG_IGN) be removed.
>
> To meet the probable intent, the signal should probably be ignored while
> writing to file operands (in case they turn out to be pipes) and enabled
> each time when writing to stdout.
>
> Sam
>
If we get EPIPE on write to stdout, then fail like a decent tee.
We fail with SIGPIPE like GNU tee as emulating GNU tee seems to be the aim.

--- ./coreutils/tee.c.o	2019-09-13 07:50:47.134804213 +0100
+++ ./coreutils/tee.c	2019-09-13 09:09:40.280881938 +0100
@@ -70,7 +70,9 @@
 	}
 	retval = EXIT_SUCCESS;
 	/* gnu tee ignores SIGPIPE in case one of the output files is a pipe
-	 * that doesn't consume all its input.  Good idea... */
+	 * that doesn't consume all its input.  Good idea... 
+	 * An even better idea is to still respect SIGPIPE on stdout
+	 * which we do further on. */
 	signal(SIGPIPE, SIG_IGN);
 
 	/* Allocate an array of FILE *'s, with one extra for a sentinel. */
@@ -100,9 +102,12 @@
 #if ENABLE_FEATURE_TEE_USE_BLOCK_IO
 	while ((c = safe_read(STDIN_FILENO, buf, COMMON_BUFSIZE)) > 0) {
 		fp = files;
-		do
+		if (fwrite(buf, 1, c, *fp) != c && errno == EPIPE)

Re: SIGPIPE and tee

[Sam Liddicott]

Here is a patch which invokes kill_myself_with_sig(SIGPIPE) if fwrite fails
with errno=EPIPE.

Quitting with a signal rather than a diagnostic output emulates GNU tee
which is in line with the apparent reason for busybox tee in ignoring
SIGPIPE in the first place.

I have tested it with and without CONFIG_FEATURE_TEE_USE_BLOCK_IO=y

As expected, dd succeeds for bs=1024 with CONFIG_FEATURE_TEE_USE_BLOCK_IO=y
but fails for without.
dd fails in both cases for bs=1024000
tee fails in both cases

( sleep 2 ; dd if=/dev/zero bs=1024000 count=5 ; echo dd $? > /dev/tty ; )
| {
build_output/sysroots-components/x86_64/busybox-native/bin/busybox.nosuid
tee /dev/null ; echo tee $? >/dev/tty ; } | sleep 1

( sleep 2 ; dd if=/dev/zero bs=1024 count=5 ; echo dd $? > /dev/tty ; ) | {
build_output/sysroots-components/x86_64/busybox-native/bin/busybox.nosuid
tee /dev/null ; echo tee $? >/dev/tty ; } | sleep 1

A colleague has suggested that *any* write failure to *stdout* by tee ought
to cause tee to quit, but I leave this to your consideration; something
like this *might* cover both cases but I haven't tested it:

if (fwrite(buf, 1, c, *fp) != c) {
  if (errno == EPIPE) kill_myself_with_sig(SIGPIPE);
  retval = EXIT_FAILURE;
  break;
}

Sam


On Thu, 12 Sep 2019 at 20:03, Sam Liddicott  wrote:

> In  https://git.busybox.net/busybox/tree/coreutils/tee.c we read:
>
>   /* gnu tee ignores SIGPIPE in case one of the output files is a pipe
>  * that doesn't consume all its input.  Good idea... */
>   signal(SIGPIPE, SIG_IGN);
>
>
> Sadly, this breaks POSIX SIGPIPE behaviour with respect to quitting when
> stdout (as a pipe) is closed.
>
> Despite the comment, GNU tee does not behave as the comment suggests.
>
> Comparing 1.27.2-2ubuntu3.2 with tee (GNU coreutils) 8.28
>
> I test with one output file and stdout that stops early causing SIGPIPE
>
> 1. GNU tee
>
> ( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( tee
> /dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null
>
> 10+0 records in
> 10+0 records out
> 100 bytes copied, 0.000387276 s, 258 kB/s
> tee 141
> done 141
>
> the first two pipeline stages have exit code 141 due to sigpipe as we
> would expect
>
> 2. busybox tee
>
> ( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( busybox tee
> /dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null
> 10+0 records in
> 10+0 records out
> 100 bytes copied, 0.000291134 s, 343 kB/s
> 8192+0 records in
> 8192+0 records out
> 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0447136 s, 188 MB/s
> done 0
> tee 0
>
> both prior pipeline elements have exit code zero and the first stage
> processed all of the data
>
> The POSIX spec for tee reads:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tee.html
> CONSEQUENCES OF ERRORS
>
> If a write to any successfully opened *file* operand fails, writes to
> other successfully opened *file* operands and standard output shall
> continue, but the exit status shall be non-zero. Otherwise, the default
> actions specified in *Utility Description Defaults*
> <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04>
>  apply.
>
> But this case deals with a failure to write to stdout, not a failure to
> write to a *file* operand.
>
> Certainly, with this behaviour, busybox tee does not comply with GNU tee
> as it appears to intend, so I suggest that the line signal(SIGPIPE,
> SIG_IGN) be removed.
>
> To meet the probable intent, the signal should probably be ignored while
> writing to file operands (in case they turn out to be pipes) and enabled
> each time when writing to stdout.
>
> Sam
>


0001-Add-SIGPIPE-handler-to-tee.patch
Description: Binary data
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: SIGPIPE and tee

[Sam Liddicott]

I also note that busybox tee treats a filename single hyphen as stdout,
contrary to POSIX.

I mention it only because it might save a few bytes to remove this special
case, and treat it as a regular file.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tee.html
OPERANDS

The following operands shall be supported:
*file*A pathname of an output file. If a *file* operand is '-', it shall
refer to a file named *-*; implementations shall not treat it as meaning
standard output.


On Thu, 12 Sep 2019 at 20:03, Sam Liddicott  wrote:

> In  https://git.busybox.net/busybox/tree/coreutils/tee.c we read:
>
>   /* gnu tee ignores SIGPIPE in case one of the output files is a pipe
>  * that doesn't consume all its input.  Good idea... */
>   signal(SIGPIPE, SIG_IGN);
>
>
> Sadly, this breaks POSIX SIGPIPE behaviour with respect to quitting when
> stdout (as a pipe) is closed.
>
> Despite the comment, GNU tee does not behave as the comment suggests.
>
> Comparing 1.27.2-2ubuntu3.2 with tee (GNU coreutils) 8.28
>
> I test with one output file and stdout that stops early causing SIGPIPE
>
> 1. GNU tee
>
> ( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( tee
> /dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null
>
> 10+0 records in
> 10+0 records out
> 100 bytes copied, 0.000387276 s, 258 kB/s
> tee 141
> done 141
>
> the first two pipeline stages have exit code 141 due to sigpipe as we
> would expect
>
> 2. busybox tee
>
> ( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( busybox tee
> /dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null
> 10+0 records in
> 10+0 records out
> 100 bytes copied, 0.000291134 s, 343 kB/s
> 8192+0 records in
> 8192+0 records out
> 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0447136 s, 188 MB/s
> done 0
> tee 0
>
> both prior pipeline elements have exit code zero and the first stage
> processed all of the data
>
> The POSIX spec for tee reads:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tee.html
> CONSEQUENCES OF ERRORS
>
> If a write to any successfully opened *file* operand fails, writes to
> other successfully opened *file* operands and standard output shall
> continue, but the exit status shall be non-zero. Otherwise, the default
> actions specified in *Utility Description Defaults*
> <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04>
>  apply.
>
> But this case deals with a failure to write to stdout, not a failure to
> write to a *file* operand.
>
> Certainly, with this behaviour, busybox tee does not comply with GNU tee
> as it appears to intend, so I suggest that the line signal(SIGPIPE,
> SIG_IGN) be removed.
>
> To meet the probable intent, the signal should probably be ignored while
> writing to file operands (in case they turn out to be pipes) and enabled
> each time when writing to stdout.
>
> Sam
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

SIGPIPE and tee

[Sam Liddicott]

In  https://git.busybox.net/busybox/tree/coreutils/tee.c we read:

/* gnu tee ignores SIGPIPE in case one of the output files is a pipe
* that doesn't consume all its input.  Good idea... */
signal(SIGPIPE, SIG_IGN);


Sadly, this breaks POSIX SIGPIPE behaviour with respect to quitting when
stdout (as a pipe) is closed.

Despite the comment, GNU tee does not behave as the comment suggests.

Comparing 1.27.2-2ubuntu3.2 with tee (GNU coreutils) 8.28

I test with one output file and stdout that stops early causing SIGPIPE

1. GNU tee

( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( tee
/dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null

10+0 records in
10+0 records out
100 bytes copied, 0.000387276 s, 258 kB/s
tee 141
done 141

the first two pipeline stages have exit code 141 due to sigpipe as we would
expect

2. busybox tee

( dd if=/dev/zero bs=1024 count=8192 ; echo done $? >&2  ) | ( busybox tee
/dev/null ; echo tee $? >&2) | dd bs=10 count=10 >/dev/null
10+0 records in
10+0 records out
100 bytes copied, 0.000291134 s, 343 kB/s
8192+0 records in
8192+0 records out
8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0447136 s, 188 MB/s
done 0
tee 0

both prior pipeline elements have exit code zero and the first stage
processed all of the data

The POSIX spec for tee reads:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/tee.html
CONSEQUENCES OF ERRORS

If a write to any successfully opened *file* operand fails, writes to other
successfully opened *file* operands and standard output shall continue, but
the exit status shall be non-zero. Otherwise, the default actions specified
in *Utility Description Defaults*

 apply.

But this case deals with a failure to write to stdout, not a failure to
write to a *file* operand.

Certainly, with this behaviour, busybox tee does not comply with GNU tee as
it appears to intend, so I suggest that the line signal(SIGPIPE, SIG_IGN)
be removed.

To meet the probable intent, the signal should probably be ignored while
writing to file operands (in case they turn out to be pipes) and enabled
each time when writing to stdout.

Sam
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: git clone fail

[Sam Liddicott]

Looks like a failing disk to me, with sporadic disk read failures.

Sam

On Tue, 4 Dec 2018 at 08:34, Xabier Oneca -- xOneca 
wrote:

> Hello,
>
> I also got a different error clonning:
>
> $ git clone https://git.busybox.net/busybox bb
> Cloning into 'bb'...  <-- stalls here for a few minutes
> error: Unable to find e9dccab9f4bf3311ae50f19e39e7e499b25edca2 under
> https://git.busybox.net/busybox
> Cannot obtain needed commit e9dccab9f4bf3311ae50f19e39e7e499b25edca2
> while processing commit 9bd8d0c23e867238bad53b04a029f71db9b88c3f.
> error: fetch failed.
>
> But then tried again and it worked. But also stalling at "cloning
> into..." for a few minutes.
>
> Cheers,
>
> Xabier Oneca_,,_
> ___
> 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: License concerns when embedding script in busybox binary

[Sam Liddicott]

On Fri, 9 Nov 2018 16:51 Michael Conrad  On 11/7/2018 10:49 AM, Ron Yorston wrote:
>
> Kang-Che Sung wrote:
>
> Specifically, I think the current state of config ASH_EMBEDDED_SCRIPTS
> help text did not yet warn builders that the binary may be distributed **only
> when the embedding scripts are GPLv2-compatible**. Builder and
> distributors may accidentally violate copyright if they didn't get careful
> at reading the BusyBox licenses. I think something should be done to make
> the warning more explicit.
>
> As I said: I don't know what the status of embedded scripts is. *Are*
> they required to be GPLv2 compatible?
>
> I'm not a lawyer either, but I'd guess they probably need to be. But, the
> main requirement is that a vendor provide the source to their customer, and
> the source is in fact being shipped because it's a script.  Anyone with gdb
> would be able to extract the table and then decompress it back to the
> original directory of scripts.  Maybe if busybox had an option to dump out
> the scripts it would help enforce the idea that the sources were being
> shipped.  Wonder how many bytes that would require…
>

A requirement not just to ship/provide the source, but to license it too!

Sam
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] libarchive: add a function to unpack embedded data

[Sam Liddicott]

Will that support an embedded .profile there as well?

Sam

On Fri, 2 Nov 2018 at 13:19, Denys Vlasenko 
wrote:

> Applied, thanks!
> On Fri, Nov 2, 2018 at 9:34 AM Ron Yorston  wrote:
> >
> > Similar code to unpack embedded data is used to decompress usage
> > messages, embedded scripts and the config file (in the non-default
> > bbconfig applet).
> >
> > Moving this code to a common function reduces the size of the default
> > build and hides more of the internals of libarchive.
> >
> > function old new   delta
> > unpack_bz2_data- 135+135
> > bb_show_usage137 157 +20
> > get_script_content32  47 +15
> > unpack_scripts   119   --119
> > unpack_usage_messages124   --124
> >
> --
> > (add/remove: 1/2 grow/shrink: 2/0 up/down: 170/-243)  Total: -73
> bytes
> >
> > Signed-off-by: Ron Yorston 
> > ---
> >  archival/libarchive/decompress_bunzip2.c | 38 +--
> >  include/bb_archive.h |  7 +-
> >  libbb/appletlib.c| 81 +---
> >  miscutils/bbconfig.c | 27 ++--
> >  4 files changed, 54 insertions(+), 99 deletions(-)
> >
> > diff --git a/archival/libarchive/decompress_bunzip2.c
> b/archival/libarchive/decompress_bunzip2.c
> > index 7ef4e035f..3deb213a8 100644
> > --- a/archival/libarchive/decompress_bunzip2.c
> > +++ b/archival/libarchive/decompress_bunzip2.c
> > @@ -107,7 +107,7 @@ struct bunzip_data {
> > uint8_t selectors[32768];  /* nSelectors=15 bits */
> > struct group_data groups[MAX_GROUPS];  /* Huffman coding tables
> */
> >  };
> > -/* typedef struct bunzip_data bunzip_data; -- done in .h file */
> > +typedef struct bunzip_data bunzip_data;
> >
> >
> >  /* Return the next nnn bits of input.  All reads from the compressed
> input
> > @@ -575,7 +575,7 @@ static int get_next_block(bunzip_data *bd)
> > in outbuf. IOW: on EOF returns len ("all bytes are not filled"), not
> 0.
> > (Why? This allows to get rid of one local variable)
> >  */
> > -int FAST_FUNC read_bunzip(bunzip_data *bd, char *outbuf, int len)
> > +static int FAST_FUNC read_bunzip(bunzip_data *bd, char *outbuf, int len)
> >  {
> > const uint32_t *dbuf;
> > int pos, current, previous;
> > @@ -699,7 +699,7 @@ int FAST_FUNC read_bunzip(bunzip_data *bd, char
> *outbuf, int len)
> >  /* Because bunzip2 is used for help text unpacking, and because
> bb_show_usage()
> > should work for NOFORK applets too, we must be extremely careful to
> not leak
> > any allocations! */
> > -int FAST_FUNC start_bunzip(
> > +static int FAST_FUNC start_bunzip(
> > void *jmpbuf,
> > bunzip_data **bdp,
> > int in_fd,
> > @@ -759,7 +759,7 @@ int FAST_FUNC start_bunzip(
> > return RETVAL_OK;
> >  }
> >
> > -void FAST_FUNC dealloc_bunzip(bunzip_data *bd)
> > +static void FAST_FUNC dealloc_bunzip(bunzip_data *bd)
> >  {
> > free(bd->dbuf);
> > free(bd);
> > @@ -847,6 +847,36 @@ unpack_bz2_stream(transformer_state_t *xstate)
> > return i ? i : IF_DESKTOP(total_written) + 0;
> >  }
> >
> > +const char * FAST_FUNC
> > +unpack_bz2_data(const char *packed, int packed_len, int unpacked_len)
> > +{
> > +   char *outbuf = NULL;
> > +   bunzip_data *bd;
> > +   int i;
> > +   jmp_buf jmpbuf;
> > +
> > +   /* Setup for I/O error handling via longjmp */
> > +   i = setjmp(jmpbuf);
> > +   if (i == 0) {
> > +   i = start_bunzip(&jmpbuf,
> > +   &bd,
> > +   /* src_fd: */ -1,
> > +   /* inbuf:  */ packed,
> > +   /* len:*/ packed_len
> > +   );
> > +   }
> > +   /* read_bunzip can longjmp and end up here with i != 0
> > +* on read data errors! Not trivial */
> > +   if (i == 0) {
> > +   /* Cannot use xmalloc: will leak bd in NOFORK case! */
> > +   outbuf = malloc_or_warn(unpacked_len);
> > +   if (outbuf)
> > +   read_bunzip(bd, outbuf, unpacked_len);
> > +   }
> > +   dealloc_bunzip(bd);
> > +   return outbuf;
> > +}
> > +
> >  #ifdef TESTING
> >
> >  static char *const bunzip_errors[] = {
> > diff --git a/include/bb_archive.h b/include/bb_archive.h
> > index d2022336b..0dbe17496 100644
> > --- a/include/bb_archive.h
> > +++ b/include/bb_archive.h
> > @@ -214,12 +214,7 @@ const llist_t *find_list_entry(const llist_t *list,
> const char *filename) FAST_F
> >  const llist_t *find_list_entry2(const llist_t *list, const char
> *filename) FAST_FUNC;
> >
> >  /* A bit of bunzip2 internals are exposed for

Re: less Idle time with busybox ash as bash vs bash

[Sam Liddicott]

Bash has some built-in too.

Sam
On 31 Aug 2018 19:11, "James Hanley"  wrote:

> We had some bash scripts that we converted to use busybox ash as bash
> (removed any array constructs) and when comparing the two scripts - it
> seems that running them under busybox yields less idle time compared
> to bash.
>
> I was expecting that busybox would (itself) take up more time simply
> because of vfork, but yield more CPU time overall since there would be
> less overhead as a number of the applets would not fork&exec.
>
> Is this expected behavior that busybox overall yields less idle time?
> -Jim
> ___
> 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: Problem with cat

[Sam Liddicott]

On 14 March 2017 at 14:44, Grant Edwards  wrote:

> On 2017-03-14, Lauri Kasanen  wrote:
> > On Mon, 13 Mar 2017 19:24:17 + (UTC)
> > Grant Edwards  wrote:
> >
> >> That paragraph is wrong (or at least misleading). I've checked the
> >> source code, and 2.6.33 does not update the output file postition (at
> >> least not the version I downloaded from kernels.org nor the version I
> >> got from Atmel). Perhaps the author of that man page had a 2.6.33 with
> >> some 3.0 stuff backported.
> >
> > Please report the bug to them. I've found the man-pages project quite
> > responsive.
>
> Done... thanks for reminding me.  Unfortunately, I can't build/test
> kernels between 2.6.33.7 (sendfile->file broken), and 3.2 (works) to
> find the exact point where the change that correctly sets the output
> file position happened.
>

And as has been said, it may not help if you did; who can know which
patches have been ported anyway.

Sam
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: potential error with adduser

[Sam Liddicott]

You are allowed to have inaccurate information in /etc/passwd.

For instance, there is nothing to check that the information in the GECOS
field [https://en.wikipedia.org/wiki/Gecos_field] is correct.

There is nothing to stop you deleting the created home directory
afterwards, and nothing to force you to update the password file if you do
delete it afterwards.

I think you want the user to have an empty home directory field; that might
be specified with: -h ""

Maybe that is what you are asking for?

Sam

On 14 December 2016 at 20:59, David Henderson 
wrote:

> Hey Tito, thanks again for the reply.  I'm not sure how that example
> is disproving my concerns. :)  It is still reflecting inaccurate
> information in /etc/passwd.
>
> Dave
>
>
> On 12/14/16, Tito  wrote:
> >
> >
> > On 12/14/2016 03:26 PM, David Henderson wrote:
> >> Thanks for the reply Tito!  No problem about the initial response - it
> >> happens. :)  To me it would seem little odd to state something in one
> >> place, but not have it in reality.  Would there be a reason to have
> >> this mismatch of information?  It has an appearance of just being
> >> messy and providing misinformation.
> >>
> >> Thanks,
> >> Dave
> >
> > Hi,
> > take as example this line from /etc/passwd
> >
> > nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
> >
> > this is an user that you would create with using -H:
> >
> > adduser -u 65534 -G nobody -h /nonexistant -H -D -s /usr/sbin/nologin
> >
> > Ciao,
> > Tito
> >
> >>
> >> On 12/14/16, Tito  wrote:
> >>>
> >>>
> >>> On 12/14/2016 07:59 AM, Tito wrote:
>  On 12/13/2016 04:46 PM, David Henderson wrote:
> > Good morning gang!  Working with the 'adduser' applet and noticed
> that
> > when specifying the '-H' parameter the /etc/passwd file still gets a
> > home directory value (which doesn't exist in the file system).  Is
> > this an error?  If no home directory was to be made, shouldn't that
> > value be blank?
> >
> > Thanks,
> > Dave
> 
>  Hi,
>  from man adduser on debian:
>  "adduser will create a home directory subject to DHOME, GROUPHOMES,
> and
>  LETTERHOMES.  The home directory can be overridden from the command
>  line
>  with the --home option"
>  In fact we don't support DHOME, GROUPHOMES, and LETTERHOMES but
>  use only the user name to create the home directory unless
>  the name is specified on the command line with the -H option.
> 
>  /* create string for $HOME if not specified already */
>  pw.pw_dir = xasprintf("/home/%s", argv[0]);
> 
>  We don't support  --no-create-home option at the moment
>  but i think it would be easy to add.
> 
>  Ciao,
>  Tito
> >>>
> >>> Sorry, I misunderstood your question and was in a rush.
> >>> So let's try to be more accurate this time.
> >>> In reality we support the -H option as you correctly
> >>> stated:
> >>>
> >>> -H  same as --no-create-home
> >>> -h alternative name for home dir rather than user's name
> >>>
> >>> but -H --no-create-home refers only to the creation of the
> >>> home dir (the mkdir) not to having it in /etc/passwd:
> >>>
> >>> "Do not create the home directory, even if it doesn't exist"
> >>>
> >>> so i think busybox is doing it correctly.
> >>>
> >>> Sorry for the previous noise.
> >>>
> >>> Ciao,
> >>> Tito
> >>>
> >>> ___
> >>> 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
> >
> ___
> 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] Compress common substrings in applet names to save space

[Sam Liddicott]

On Wed, Apr 20, 2016 at 1:03 PM, Denys Vlasenko 
wrote:

> On Wed, Apr 20, 2016 at 12:55 PM, Guillermo Rodriguez Garcia
>  wrote:
> >>> When strings are abbreviated the new find_applet_by_name() is about
> >>> 34% slower than currently.  (All comparisons are for the default
> >>> configuration.)
> >>
> >> Crazy :D
> >
> > Is this really worth it? 34% slower may have a visible impact if applets
> are
> > executed frequently. And then there's the added complexity. All of that
> for
> > just some 500 bytes ?
>
> In busybox land, 500 bytes are not small.
>
> However, I also think that this idea is slightly too insane...
>

I wondered if I was reading an entry for the underhanded C contest.

Sam
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] blkdiscard: check that the file is a block device before opening

[Sam Liddicott]

This patch just trades one undefined behaviour for another.

I'd open first and then do fstat.
Otherwise change your comment, because it isn't really enforcing anything
with a race condition between the stat and the open.

Sam

On Tue, Jan 5, 2016 at 11:50 AM, Ari Sundholm  wrote:

> We need to enforce that the opened file is a block device, as
> opening a file with the O_EXCL flag on and the O_CREATE flag off has
> undefined behavior unless the file is a block device.
>
> Signed-off-by: Ari Sundholm 
> ---
>  util-linux/blkdiscard.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/util-linux/blkdiscard.c b/util-linux/blkdiscard.c
> index ace88a1..1b234fa 100644
> --- a/util-linux/blkdiscard.c
> +++ b/util-linux/blkdiscard.c
> @@ -38,7 +38,7 @@ int blkdiscard_main(int argc UNUSED_PARAM, char **argv)
> uint64_t offset; /* Leaving these two variables out does not  */
> uint64_t length; /* shrink code size and hampers readability. */
> uint64_t range[2];
> -// struct stat st;
> +   struct stat st;
> int fd;
>
> enum {
> @@ -51,11 +51,15 @@ int blkdiscard_main(int argc UNUSED_PARAM, char **argv)
> opts = getopt32(argv, "o:l:s", &offset_str, &length_str);
> argv += optind;
>
> +   /* We need to enforce that the opened file is a block device, as
> +* opening a file with the O_EXCL flag on and the O_CREATE flag
> off has
> +* undefined behavior unless the file is a block device.
> +*/
> +   xstat(argv[0], &st);
> +   if (!S_ISBLK(st.st_mode))
> +   bb_error_msg_and_die("%s: not a block device", argv[0]);
> +
> fd = xopen(argv[0], O_RDWR|O_EXCL);
> -//Why bother, BLK[SEC]DISCARD will fail on non-blockdevs anyway?
> -// xfstat(fd, &st);
> -// if (!S_ISBLK(st.st_mode))
> -// bb_error_msg_and_die("%s: not a block device", argv[0]);
>
> offset = xatoull_sfx(offset_str, kMG_suffixes);
>
> --
> 1.9.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: Good Bye

[Sam Liddicott]

I give my sincere thanks for the gift of your intellect and effort to
the world, for the care in the upkeep and maintenance of this work.

I wish you well for whatever you do next.

Sam Liddicott

On Mon, Nov 9, 2015 at 8:13 PM, Harald Becker  wrote:
> Hi All,
>
> everything comes to an end. Looks like my active development has reached
> this end.
>
> After a long and hard phase of decision I'm going to stop all of my
> development work, not only for Busybox, for all projects. The reasons for
> this are difficult, have just cumulated and don't belong only to the last
> discussions I had here.
>
> So the last I want to say is, thank you to those who responded and gave
> input, in any way.
>
> The mail address is unsubscripted from the list soon, but will stay valid
> until the end of this year. For those who like to stay in contact, send me a
> message, I will respond with a different address which should be kept valid.
>
> Good Bye
> Harald
>
> ___
> 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] umount: always use umount2 syscall with specified flags

[Sam Liddicott]

Some discussion on better encapsulations of the technique here:
http://stackoverflow.com/questions/174356/ways-to-assert-expressions-at-build-time-in-c

Sam

On Sat, Oct 3, 2015 at 11:58 AM, Xabier Oneca -- xOneca 
wrote:

> Hello,
>
> Excuse my ignorance, but what does this typedef do?
>
> --
> {
> typedef char bug[
> (OPT_FORCE != MNT_FORCE || OPT_LAZY != MNT_DETACH) ? -1 : 1
> ];
> }
> --
>
> My understanding is that this snippet catches when those two constants
> are not equal and then trigger a compiler error by defining a char[-1]
> type. Am I correct? If so, why isn't used the preprocessor #errror
> with a less cryptic error description?
>
> In a test I did:
>
> --
> test.c: In function ‘main’:
> test.c:9:18: error: size of array ‘bug’ is negative
>  typedef char bug[
>   ^
> --
>
> The bug is not so obvious to identify until you inspect the source code...
>
> Thanks!
>
> Xabier Oneca_,,_
>
> 2015-10-01 18:52 GMT+02:00 Denys Vlasenko :
> > Applied, thanks!
> ___
> 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 2/2] ash: use alloca to get rid of setjmp

[Sam Liddicott]

On 1 Jul 2015 19:36, "Rich Felker"  wrote:
>
> On Wed, Jul 01, 2015 at 04:46:18PM +0100, Ron Yorston wrote:
> > Now that the only thing protected by setjmp/longjmp is the saved string,
> > we can allocate it on the stack to get rid of the jump.
> >
> > Based on commit bd35d8e from git://
git.kernel.org/pub/scm/utils/dash/dash.git
> > by Herbert Xu.
>
> In general alloca is unsafe. It's not obvious to me what the code here
> is doing, so I can't tell for sure if it's safe or not, but I think
> this needs a strong justification of safety before being acceptable.

If you are allocating small amounts of memory then allocated is as safe as
calling a function - i.e. marginally increases the chance of stack overflow
by moving the stack pointer closer to it's limit.

Compare the size of the allocated to the saving of not needing the other
stack based variables, including jmploc.

Sam
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ntpd daemon

[Sam Liddicott]

On Thu, Mar 5, 2015 at 1:03 PM, Denys Vlasenko 
wrote:

> On Thu, Mar 5, 2015 at 11:43 AM, Laszlo Papp  wrote:
> > The problem is not when no peer is defined. The problem is when the
> > peer is defined, but we cannot talk to it. Therefore, the issue that I
> > raised is still [not] addressed with regards to this.
>
> This is not an easy thing to decide.
>
> If -p PEER doesn't resolve, what to do? Exit? Drop this peer?
> Retry? For how long?
>
> More to it. What if ntpd runs for months/years? What if PEER's
> IP changes? (We can't assume IP address of the server NEVER change)
> Do we need to re-resolve the name once in a while?
>
> Implementing any of this would require adding more code
> and more knobs (such as "how many retries to do"?).
>
> I decided that for now we are okay with a simplest solution.
> Complications can be added when a user will demonstrate
> a real-world case where he _had to_ fix a problem.
>

I have a real use case.

I wasn't using ntp but msntp because I was trying to track a local time
which might not be a stable time server. Once msntp could no longer
validate the time with the local server, or the error was too great for
adjtime, it would quit, and I would re-start it from a script loop, and so
the hostname to msntp would get re-resolved.

I give this as a real world case that for long term time tracking, it is
important to be able to re-resolve the name.

However in the case that initial resolution also failed, I felt it OK to
abort; only when initial resolution AND ntp response were obtained did I
feel it worth entering the loop to attempt re-resolution when failure
ultimately occurs.

Sam
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: In regard to CVE-2014-7169 CVE-2014-6271

[Sam Liddicott]

Many of the programs that inject environment variables could rightly
sanitise their data.

It may provide relief for system builders that provide updated busybox but
not updated bash.

Or safety where stupid use of eval is made in scripts, or careless use of
system/popen is made in programs.

To my mind system/popen are the worst culprits as data is rarely shell
quoted.

For running system commands i always recommend using fork/exec not
system/popen but this is harder if a pipeline is to be invoked or
environment variables to be directly used, in such cases I recommend this
type of construction:

("sh", "-c", "cd \"$HOME\" && \"$0\" \"$@\" ", script, user, key)

any meta characters in script, user, key will not be interpolated by the
shell. The $0 and $@ can of course be broken out to $2 $3 etc.

A wrapper for putenv to ensure that the data is of the intended format
seems a curious solution, it would lead to unexpected code paths where
either putenv fails (which should arguably be dealt with) or the data
placed is unexpectedly wrong when the error should have been dealt with
earlier... and yet it has aspects of graceful degradation which are
important when genuine but unexpected data in the wild is presented.

So the argument to sanitise putenv to me has more weight when considering
general shell injection than this particular bash error.

and yet, I'm not quite convinced yet.

Sam
On 26 Sep 2014 20:53, "Sean Mathews"  wrote:

> In regard to CVE-2014-7169 CVE-2014-6271 looking at
> busybox-1.22.1/networking/udhcp/dhcpc.c line 403 fill_envp() it seems as if
> it would be trivial to mess with bootfile and inject a packet that has
> garbage in the bootfile and exploit this vulnerability.  Something as
> trivial as removing some characters would likely be sufficient to protect
> from an exploit.
>
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_277
>
> In any case at any point in the code where the outside is allowed to
> inject directly into the shell environment data needs to be sanitized the
> same as one would sanitize a form post on a website application.
>
> here are other files that have the same issue
>  networking/httpd.c <- Yep seems easy to exploit.
>  networking/ntpd.c <- seems ok but needs more digging. Mostly sanitized by
> numerics.
>  networking/tcpudp.c <- potential via dns poisoning injecting an invalid
> hostname containing a payload.
>  mailutils/reformime.c <- uses data from mail header and places into env.
>
> I see others but they look less likely.
>
>  A wrapper fix for all set/putenv seems reasonable if it can be crafted to
> identify the use of (). I don't see how we can sanitize to a specific
> character set such as 3.278 for all environment vars and not cause problems
> with some use cases. Looking for just () has issues in that other vectors
> may be discovered down the road so maybe pushing this to fixes in bash is
> the best solution.
>
>  I would like to see generalized sanitization at every point where
> put/setenv is used to conform at minimum to the expected data that would be
> placed in the environment. Unfortunately for things like httpd.c most
> browsers do not conform to RFC2616 and quote special characters like ( in
> headers. So it would be trivial to inject a forged user agent header with
> the exploit in it.
>
> Does anyone here want to chime in on this issue and potential fixes?
>
>
> Best Regards
>  Sean Mathews
>  CTO / Director of R&D @ NuTech.com
>
>
>
> ___
> 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: shutdown busybox and start another PID1 process

[Sam Liddicott]

This works in busybox ash

getch() {
  read -t 1 -n 1 $1
}


getch key
echo $key

you probably also want stty -echo before you start

Sam


On Tue, Aug 12, 2014 at 5:44 AM, James Bowlin  wrote:

> On Mon, Aug 11, 2014 at 07:35 PM, Harald Becker said:
> > Did I get it right?
>
> This is very close to what I'm doing now.  The two changes are:
>
>   1) I boot into Debian so I switch_root into their /sbin/init
>  and I use "telinit u" to get back pid 1.
>
>   2) I copy busybox et al. into the new root before switching
>  so I don't need to unpack.  I suppose unpacking is slightly
>  safer but I have things I need to communicate to the booted
>  systems anyway.  This is partly a holdover from Knoppix
>  design I started with that used symlinks instead of a
>  switch_root.  Then I moved to bind mounts which were much
>  better but eventually a few programs were unhappy with them
>  so I ended up with the switch_root and I copied the BB stuff
>  over so programs on the booted system that I communicated to
>  didn't need to be changed.
>
>  I also like the consistency of having my busybox stuff almost
>  always under /live even though I have to copy things around
>  to make it so.
>
> BTW: I wrote a space invaders game in busybox-shell, although I
> cheated a little and wrote a tiny C program called getch that
> gives me non-blocking input.  Maybe there is already a way to
> do that built in.  If not, a getch applet might be very handy.
> It is a small thing but it is all that is needed to write
> truly interactive scripts with just busybox.  IMO it would
> open the door to some really neat things.
>
>
> Peace, James
> ___
> 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: shutdown busybox and start another PID1 process

[Sam Liddicott]

I wonder if cgroups or namespaces have any role here.

The initrd mounts NTFS and then creates a new namespace for new init which
can't see or kill fuse.

Sam
On 11 Aug 2014 17:34, "James B"  wrote:

> Hi James (from another James).
>
> On Mon, 11 Aug 2014 03:17:52 -0600
> James Bowlin  wrote:
>
> >
> > There was a need to have static root persistence where the
> > changes are saved directly in the root persistence file so I
> > needed to bite the bullet and finally get clean umounts during
> > shutdown.
> >
> > Previously, filesystems were consistently reporting they were
> > uncleanly mounted.  I wanted to do it all cleanly.  I tried like
> > crazy to get remounting read-only to work but I just could not do
> > it.  Maybe the problem was that I couldn't remount the rw file
> > system under the aufs as ro (because the aufs was rw) and I
> > couldn't remount the aufs as ro because its mount options are
> > unconventional.
>
> This is a solved problem. Fatdog64, an 64-bit offshot of Puppy Linux
> (disclaimer: I'm one of the maintainers), does exactly this - and have
> clean unmounts on common filesystems - fat32, ext2/3/4, ntfs (through
> ntfs-3g). The key is to remount ro the aufs layers; once made ro you can
> "unbind" them one by one (including the r/w layer). This ability to
> dynamically bind/unbind layers is one of the thing that makes me loves aufs
> so much - it is so much more versatile than any other layered filesystem
> out there *combined*. Get the ISO and take a look at its
> /etc/rc.d/rc.cleanup if you're interested.
>
> >
> > Well busybox has all the tools I need.  The tmpfs gives me a place
> > to stand so I can move the world^H^H aufs file system. It gives me
> > a place where my tools and everything I need are off of the aufs.
>
> Agreed, busybox is all you need.
>
> >
> > I pivot onto a tmpfs that has the busybox stuff and very little
> > else.  Root could easily erase it all.  Since it is tmpfs there
> > is no need to umount it at all.  The point is to finish the
> > shutdown from a tmpfs so I can cleanly umount the aufs and the
> > filesystems under it including the file system on the host
> > machine or on the LiveUSB.
>
> My latest solution does pivot_root too for cleanliness reason, but it is
> actually unnecessary. You can still be on your original aufs root and take
> off the layer one by one - if you're careful - and have a clean unmount.
>
> >
> > >   Hehe. I like to say that initrd/initramfs is useless, [...]
> >
> > It is required for a live system.
>
> James, you won't convert Laurent :) I tried that before.
> I however is in the complete agreement with you. Initramfs is
> indispensable for this.
> Anyway, to each his own.
>
> ---
>
> If you really want to tell busybox init to quit - the simplest thing is to
> send SIGQUIT to it (kill -3 1). Once you do that, busybox init will execute
> all the ::shutdown scripts in /etc/inittab; and when done, it will exec to
> anything you put in ::restart. Whatever command you put in ::restart will
> run as pid 1 when all is said and done. This is however isn't useful for
> clean unmount because if you happen to use ntfs-3g, it will get killed too
> before it has the chance to unmount cleanly.
>
> cheers!
> James
>
> --
> James B 
> ___
> 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: shutdown busybox and start another PID1 process

[Sam Liddicott]

On 11 Aug 2014 07:06, "Laurent Bercot"  wrote:
>
>  Come back to the candy store any time you want. Not only do we
> have some yummy candy, but you may also have some brands to share
> that we're not familar with!

White fudge?

>
> --
>  Laurent
>
>
> ___
> 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: shutdown busybox and start another PID1 process

[Sam Liddicott]

Don't forgot umount -fl which pretends to unmount now but actually does it
as soon as all files are closed.

Not sure right now if busybox supports it.

Sam
On 10 Aug 2014 22:51, "Laurent Bercot"  wrote:

> I don't quite understand what you are suggesting.
>>
>
>  Ah, I'm sorry, I hadn't realized you were not the OP, and I have
> replied as if you were trying to bring up a system - but you are
> just trying to shut it down.
>
>  Well a shutdown isn't really something I've mastered. I've always
> considered it was easy: politely ask processes to stop, then ask a
> bit less politely, then nuke everything, then unmount the
> filesystems, done. Nothing fancy here.
>
>  But indeed, FUSE daemons make it a bit trickier - you have to
> shoot stuff in the right order and interleave unmounts with kills.
> I have no expertise to share though - *you* are, probably, the
> local expert. :)
>
>
>  gentle by doing a TERM kill before I pivot_root to let children
>> spawn.  That's an easy modification.
>>
>
>  I don't understand why you would pivot_root to shutdown. Who
> cares what your rootfs is, since the system isn't going to live
> anyway ? I'd even argue that you want to keep your current
> rootfs: it's been proven to work (since the system was live on it),
> it's functional and full of utilities you may need, whereas
> switching to a new rootfs is always error-prone and cumbersome,
> you need a new set of utilities, etc. It feels needlessly complex
> to me not to use the rootfs you have.
>
>
>   pkill [--signal ] -v 
>>
>
>  Be aware that pkill, pgrep et al. all perform a /proc scan, like
> killall5 and similar utilities. They will definitely slow down your
> shutdown process if you use too many of them. I guess there's no
> choice when you have to do complex stuff, but I'd try to reduce
> their use to the strict minimum.
>  My approach would probably be to try something like:
>  - Before killing anything else, do the following atomically:
>* find processes holding an open file in a FUSE mount, with
> lsof and /proc/$pid/smaps and things like that
>* kill them
>* unmount the FUSE filesystems
>  - nuke from orbit, there's nothing left preventing me from doing it
>
>
>  I agree.  ISTM that doing "kill -TERM " and then waiting
>> a few seconds (if needed) before the pivot_root is a simple
>> and gentle solution.  I'll still follow up with a "kill -TERM"
>> and then "kill -KILL" after the pivot_root.  As you have made
>> me realize, killing after a pivot_root is an effective way
>> of dealing with the child problem.
>>
>
>  Well I still don't understand why you want a pivot_root at the end
> of your system's lifetime. It's like taking a very old and terminally
> ill person to a hospice instead of letting them die at home where
> they have lived all their life. Home is working for them, why change
> what works at this point ?
>
> --
>  Laurent
>
> ___
> 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: shutdown busybox and start another PID1 process

[Sam Liddicott]

You can replace /sbin/init with a bind mount; e.g.

mount /tmpfs/sbin/init.shutdown /sbin/init -o bind

that will replace init, but only till the next reboot.

When debugging the first couple of lines should be something like:

exec >/dev/ttyS0 2>&1 # if serial console
exec >/dev/tty1 2>&1 # if normal console
set -x # debug script output
and maybe:
trap "sleep 10" 0 # so that you can have time to read final error messages
before it reboots

On Sat, Aug 9, 2014 at 11:44 PM, James Bowlin  wrote:

> On Sat, Aug 09, 2014 at 01:02 PM, Rieker Flaik said:
> > There I can exec busybox its normal init "/sbin/init". This is
> > what I want to use in this pre-OS, having a nice init system to
> > spawn all kinds of programs like udhcp and dropbear to do the
> > backup stuff.
>
> It is actually very easy to get control back from /sbin/init.
>
> Replace /sbin/init with the script you want to run.  Then run the
> command:
>
> telinit u
>
> This tells the init process to shutdown and restart.  When it
> restarts, your script at /sbin/init is what will run.
>
> Before you start playing with this, do:
>
> sudo ls -l /proc/1/fd
>
> and notice that most standard IO is turned off (at least on my
> systems).  If you want PID-1 to be a shell again then you will
> need to reconnect some IO.
>
> Some LiveCD/USB systems use this trick to get PID-1 to run from a
> small (RAM based) busybox system during shutdown.  The great
> thing about this is it gives you the ability to have shell access
> throughout the shutdown process even after all non-RAM file
> systems have been unmounted.
>
> IMO this is actually more stable and more robust than the
> conventional way Linux systems shut down.  The major cost
> is the 1-Meg or so of RAM needed the tmpfs for busybox.  I think
> the Linux distros should migrate to using busybox for the
> shutdown process even when not running live.
>
> Peace, James
> ___
> 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] getty: remove the statement of pid and sid comparison

[Sam Liddicott]

Maybe "&& true" is better than "; true" so that the correct exit code will
also be returned.

Sam
On 10 May 2014 23:19, "Denys Vlasenko"  wrote:

> On Saturday 10 May 2014 04:17, Zhenhua Luo wrote:
> > when setsid failed, the pid and sid doesn't equal, so remove following
> > condition statement.
> > if (getsid(0) != pid)
> >
> > Following is the content and output of test program.
> > root@p1022ds:~# cat sid_test.c
> >
> > int main() {
> > pid_t pid;
> >
> > pid = setsid();
> > if (pid < 0) {
> > int fd;
> > pid = getpid();
> > if (getsid(0) != pid) {
> >  printf("setsid failed: pid %d ppid %d sid %d pgid %d",
> >   pid, getppid(),
> >   getsid(0), getpgid(0));
> > }
> > }
> > }
> >
> > root@p1022ds:~# ./sid_test
> > setsid failed: pid 2452 ppid 2408 sid 2408 pgid 2452
>
> It fails because it is a process group leader.
> Its pid is a process group id.
>
> If it would succeed, it should create new session
> *and new process group* with the pgid == pid.
> But it's not possible to have two process groups with the same pgid.
> What to happen to other members of existing PG?
>
> Of course, this wouldn't be a problem if this PG has only one
> member - this process.
> But kernel doesn't check for this case, it just fails
> setsid() if process is a process group leader.
>
>
> > root@p1022ds:~#
> >
> > Fix following runtime issue of getty:
> > root@p1025:~# getty 115200 /dev/ttyQE1
> > getty: setsid: Operation not permitted
>
> I'm not sure about this.
>
> The programs called from getty (e.g. login) expect to be session leaders.
> Giving them that *sometimes* can lead to puzzling behavior
> when something "sometimes works".
>
> I feel that failing outright is better.
>
> Try:
>
> # sh -c 'getty 115200 /dev/ttyQE1; true'
>
> (the "...; true" part is to prevent "last command can be exec-ed"
> optimization
> done by some shells)
>
> This way, getty isn't a process group leader, and setsid() works.
> ___
> 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: bug in busybox sed with non-ascii chars

[Sam Liddicott]

One of the advantages of utf-8 encoding was that it was easy to re-sync
after an invalid sequence.

It's a bit of a waste to then not do that. Minus points for musl.

Can you not run sed with LANG=C or LANG=POSIX?

Sam
On 4 May 2014 15:57, "Rich Felker"  wrote:

> On Sun, May 04, 2014 at 04:44:10PM +0200, Denys Vlasenko wrote:
> > On Sat, May 3, 2014 at 5:07 PM, Rich Felker  wrote:
> > >> Lets refuse to find end of line if there is a non UTF-8 sequence
> inside that line?
> > >> Sounds wrong to me...
> > >
> > > sed (also regcomp and regexec) requires text input. Byte streams with
> > > illegal sequences are not text. Actually since the regex is not trying
> > > to match the illegal sequence, just the end-of-line, it would
> > > theoretically be possible to make this work (and it will once we
> > > overhaul the regex implementation to work with byte-based DFA's rather
> > > than character-based ones), but that doesn't change the fact that it's
> > > an invalid test.
> >
> > Language lawyering is less important that real world usage.
>
> Indeed it's nice to support additional real-world usage when doing so
> does not harm any other usage. But we're not talking about real-world
> usage here. We're talking about a buggy configure test.
>
> I'd love to improve or even rewrite the regex engine but that's a lot
> of work and lower priority than a number of other things on the musl
> roadmap.
>
> Rich
> ___
> 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: Compiling using LLVM Clang : Nested functions

[Sam Liddicott]

0001-Support-compilers-without-nested-functions.patch
Description: Binary data
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Patch for udhcpc hwtype

[Sam Liddicott]

--- networking/udhcp/dhcpc.c.orig	2010-10-11 14:15:04.0 +0100
+++ networking/udhcp/dhcpc.c	2010-10-11 14:15:28.0 +0100
@@ -145,6 +145,7 @@
 	int tryagain_timeout = 20;
 	int discover_timeout = 3;
 	int discover_retries = 3;
+	int hwtype = 1;
 	uint32_t server_addr = server_addr; /* for compiler */
 	uint32_t requested_ip = 0;
 	uint32_t xid = 0;
@@ -162,6 +163,7 @@
 #if ENABLE_LONG_OPTS
 	static const char udhcpc_longopts[] ALIGN1 =
 		"clientid\0"   Required_argument "c"
+		"clientid-hwtype\0"  Required_argument "w"
 		"clientid-none\0"  No_argument   "C"
 		"vendorclass\0"Required_argument "V"
 		"hostname\0"   Required_argument "H"
@@ -188,27 +190,28 @@
 #endif
 	enum {
 		OPT_c = 1 << 0,
-		OPT_C = 1 << 1,
-		OPT_V = 1 << 2,
-		OPT_H = 1 << 3,
-		OPT_h = 1 << 4,
-		OPT_F = 1 << 5,
-		OPT_i = 1 << 6,
-		OPT_n = 1 << 7,
-		OPT_p = 1 << 8,
-		OPT_q = 1 << 9,
-		OPT_R = 1 << 10,
-		OPT_r = 1 << 11,
-		OPT_s = 1 << 12,
-		OPT_T = 1 << 13,
-		OPT_t = 1 << 14,
-		OPT_S = 1 << 15,
-		OPT_A = 1 << 16,
-		OPT_O = 1 << 17,
-		OPT_o = 1 << 18,
-		OPT_f = 1 << 19,
+		OPT_w = 1 << 1,
+		OPT_C = 1 << 2,
+		OPT_V = 1 << 3,
+		OPT_H = 1 << 4,
+		OPT_h = 1 << 5,
+		OPT_F = 1 << 6,
+		OPT_i = 1 << 7,
+		OPT_n = 1 << 8,
+		OPT_p = 1 << 9,
+		OPT_q = 1 << 10,
+		OPT_R = 1 << 11,
+		OPT_r = 1 << 12,
+		OPT_s = 1 << 13,
+		OPT_T = 1 << 14,
+		OPT_t = 1 << 15,
+		OPT_S = 1 << 16,
+		OPT_A = 1 << 17,
+		OPT_O = 1 << 18,
+		OPT_o = 1 << 19,
+		OPT_f = 1 << 20,
 /* The rest has variable bit positions, need to be clever */
-		OPTBIT_f = 19,
+		OPTBIT_f = 20,
 		USE_FOR_MMU( OPTBIT_b,)
 		IF_FEATURE_UDHCPC_ARPING(OPTBIT_a,)
 		IF_FEATURE_UDHCP_PORT(   OPTBIT_P,)
@@ -225,18 +228,18 @@
 
 	/* Parse command line */
 	/* Cc: mutually exclusive; O: list; -T,-t,-A take numeric param */
-	opt_complementary = "c--C:C--c:O::T+:t+:A+"
+	opt_complementary = "c--C:C--c:O::T+:t+:A+:w+"
 #if defined CONFIG_UDHCP_DEBUG && CONFIG_UDHCP_DEBUG >= 1
 		":vv"
 #endif
 		;
 	IF_LONG_OPTS(applet_long_options = udhcpc_longopts;)
-	opt = getopt32(argv, "c:CV:H:h:F:i:np:qRr:s:T:t:SA:O:of"
+	opt = getopt32(argv, "c:w:CV:H:h:F:i:np:qRr:s:T:t:SA:O:of"
 		USE_FOR_MMU("b")
 		IF_FEATURE_UDHCPC_ARPING("a")
 		IF_FEATURE_UDHCP_PORT("P:")
 		"v"
-		, &str_c, &str_V, &str_h, &str_h, &str_F
+		, &str_c, &hwtype, &str_V, &str_h, &str_h, &str_F
 		, &client_config.interface, &client_config.pidfile, &str_r /* i,p */
 		, &client_config.script /* s */
 		, &discover_timeout, &discover_retries, &tryagain_timeout /* T,t,A */
@@ -246,8 +249,14 @@
 		, &dhcp_verbose
 #endif
 		);
-	if (opt & OPT_c)
+	if (opt & OPT_c) {
+		if (opt & OPT_w) {
+			client_config.clientid = alloc_dhcp_option(DHCP_CLIENT_ID, str_c, 1);
+			client_config.clientid[2] = hwtype & 255;
+		} else {
 		client_config.clientid = alloc_dhcp_option(DHCP_CLIENT_ID, str_c, 0);
+		}
+}
 	if (opt & OPT_V)
 		client_config.vendorclass = alloc_dhcp_option(DHCP_VENDOR, str_V, 0);
 	if (opt & (OPT_h|OPT_H))
@@ -317,7 +326,7 @@
 	/* If not set, and not suppressed, set up the default client ID */
 	if (!client_config.clientid && !(opt & OPT_C)) {
 		client_config.clientid = alloc_dhcp_option(DHCP_CLIENT_ID, "", 7);
-		client_config.clientid[OPT_DATA] = 1;
+		client_config.clientid[OPT_DATA] = hwtype & 255;
 		memcpy(client_config.clientid + OPT_DATA+1, client_config.client_mac, 6);
 	}
 
--- include/usage.h.orig	2010-10-11 14:35:42.0 +0100
+++ include/usage.h	2010-10-11 14:35:46.0 +0100
@@ -4799,6 +4799,7 @@
  "\n	-H,-h,--hostname=HOSTNAME	Client hostname" \
  "\n	-c,--clientid=CLIENTID	Client identifier" \
  "\n	-C,--clientid-none	Suppress default client identifier" \
+ "\n	-w,--clentid-hwtype=N	Prefix clientid with hwtype (see RFC2132, RCF1700) " \
  "\n	-p,--pidfile=FILE	Create pidfile" \
  "\n	-r,--request=IP		IP address to request" \
  "\n	-s,--script=FILE	Run FILE at DHCP events (default "CONFIG_UDHCPC_DEFAULT_SCRIPT")" \
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox