gmane.linux.busybox

[PATCH] sulogin: allow system maintenance login if root password is empty

Jonathan Liu — 2013-05-20T11:07:33

The current password checking is unable to distinguish between the user
entering an empty password or pressing Control-D. As a result, an empty
password always results in normal startup.

We modify bb_ask to store the EOF status after the null terminator if
the password is empty. This allows sulogin to properly check if
Control-D was pressed.

Signed-off-by: Jonathan Liu <net147< at >gmail.com>
---
 libbb/bb_askpass.c   | 3 +++
 loginutils/sulogin.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/libbb/bb_askpass.c b/libbb/bb_askpass.c
index fe2b506..4df0901 100644
--- a/libbb/bb_askpass.c
+++ b/libbb/bb_askpass.c
< at >< at > -75,6 +75,9 < at >< at > char* FAST_FUNC bb_ask(const int fd, int timeout, const char *prompt)
  || ++i == sizeof_passwd-1 /* line limit */
 ) {
 ret[i] = '\0';
+/* if empty, store EOF status after null terminator */
+if (i == 0)
+ret[i + 1] = (r == 0);
 break;
 }
 }
diff --git a/loginutils/sulogin.c b/loginutils/sulogin.c
index bd2b09e..9fcf530 100644
--- a/loginut

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-20T07:50:16

Hi Jeremy !


Not signal. A location/file in shared memory. Handled outside of
init. The usual way to pass information to such kind of
routines/scripts in Unix like systems.

The restart handler is just a script. The script is invoked (via
exec) after normal shutdown is done, then grabs the information
from a shared memory location what to do next. After that the
restart script can do whatever is required. Not only those four
shutdown actions. This way allows us to have an unlimited number
of shutdown types without adding further cases to init (or using
extra signals). That's the way it has bean done for so many years
on many different machines and Unix like systems.

Original sysvinit uses RUNLEVEL to pass such kind of information,
but this has been superseded by passing information through
a shared memory location.

IMO we have already more cases than required. A single trigger
and the possibility to pass on a value to the restart action
would be enough. Then we have more flexibility with less
cases.

--
H

Re: [PATCH] init: handle kexec clean reboot

Jeremy Kerr — 2013-05-20T07:13:40

Hi Harald,


Yep, and my original patch adds a forth to the same path the
halt/reboot/poweroff. This is slightly different to the restart path:
halt_reboot_pwoff() vs. restart_handler().


No, I was worried that registering a restart handler would affect normal
reboot. But fortunately, that's not the case.



You mean signals? Or am I looking at the wrong code?

I think I see what you're saying with the restart handler, but it seems
a little fragile: With the patch, we just to invoke `reboot -k`. Without
the patch, we need to ensure that inittab has the correct restart
handler, then SIGHUP init if inittab was modified, then SIGQUIT init to
do the actual shutdown & kexec.

Granted, systems that are expected to kexec can have inittab
pre-configured with a restart handler that calls `kexec -e`, but this
means that the kexec path depends on a specific configuration which
isn't obvious.

Cheers,


Jeremy

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-20T06:56:11

Hi Jeremy !


We have already three types of shutdown: halt, reboot and
poweroff. All three are handled by the same restart action and
need what you call "dynamic reconfiguration". You may just pass
required information via shared memory. In most cases I know, it
is handled this way.

--
Harald

Re: [PATCH] init: handle kexec clean reboot

Jeremy Kerr — 2013-05-20T06:52:57

Hi all,


Hm, it looks like we can indeed set up kexec as a "permanent" restart
handler without affecting normal reboot.

This assumes that we don't end up restarting for other reasons; is this
a valid assumption (and not a horrible misuse of an existing feature :))?

Cheers,


Jeremy

Re: [PATCH] init: handle kexec clean reboot

Jeremy Kerr — 2013-05-20T06:43:13

Hi Harald,


That's what I'd like to find out :)


That seems a little bit clunky; we may not always want the restart
action to be a kexec (but just a normal reboot). In this case, would we
need to be dynamically reconfiguring the restart action?

My thinking here is that a kexec reboot is almost identical to a normal
reboot, only varying in the argument to the reboot() syscall. So, might
as well use the the existing infrastructure to do this.

Cheers,


Jeremy

[Harald: sorry for the resend, missed the list...]

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-20T06:15:16

Hi Jeremy !


Do we really need this? Busybox init has a restart action. If
this action is set to a script it is invoked after normal
shutdown processing. The script may do whatever action may be
required or optionally restart the init process.

IMO if you really want to extend init we should do it in a
compatible fashion and invoke an action script. The script is
free to do whatever is required.

--
Harald

[PATCH] init: handle kexec clean reboot

Jeremy Kerr — 2013-05-20T05:49:31

Currently, busybox init won't allow us to do a clean kexec; we have to
invoke kexec -e, which calls the reboot(LINUX_REBOOT_CMD_KEXEC) system
call directly, bypassing any shutdown/reboot init actions.

It'd be better if we can halt the system properly before the kernel
kexec, in order to unmount filesystems, take network devices down, etc.

As far as I can tell, this is handled in other inits in differring ways:
A kexec on systemd is performed by invoking `systemctl kexec`,
(alternatively `shutdown -r` will detect the presence of a loaded kexec
and change the reboot() magic accordingly). Upstart doesn't seem to
have native kexec support, so a clean kexec on Ubuntu is implemented
with an init script that calls `kexec -e` late in the shutdown path and
never returns.

This change adds a '-k' option to /sbin/reboot, which tells init (via
a SIGALRM) that we're requesting a kexec rather than a normal reboot.
init then handles this by specifying the correct magic to the reboot
syscall.

RFC: a couple of open items:

Re: [PATCH] BusyBox 1.19.4 + 1.21.0 stty add RS485 config options

Denys Vlasenko — 2013-05-19T13:05:38

I see.

The point is, I prefer for busybox commands to be similar to the
"standard" commands (where "standard" is defined as "commands
which are found on the most popular Linux distributions")

Please submit your patches to the upstream projects first,
so that they are accepted by standard tools.

Then the corresponding support can be added to busybox.

Re stty: stty seems to be oriented to setting termios parameters.

Hardware-dependent paramentes for serial ports are set by another tool,
setserial. From my POV rs485 support would look more natural there.

[PATCH] BusyBox coreutils stty add RS485 config options

Angeli Janos — 2013-05-18T21:33:33

Dear Denys,

I've attached my fixed patches for adding RS-485 configuration options 
to BusyBox coreutils stty. The previous version can't compiled with old 
(pre 2.6.35) linux kernel headers. The two patches are for the latest 
stable 1.21.0 and the current git master version.

Best Regards,
Janos Angeli

_______________________________________________
busybox mailing list
busybox< at >busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] BusyBox 1.19.4 + 1.21.0 stty add RS485 config options

Angeli Janos — 2013-05-18T20:17:00

Dear Denys,

On 2013.05.17. 18:25, Denys Vlasenko wrote:
No, I haven't sended it yet. I've already checked the original coreutils 
stty source code, It's a little bit different from Your BusyBox version, 
but I can make a patch for it and send it to the list. (Maybe the RS-485 
configurations can be useful for non embedded systems too.)

Currently very few serial drivers supports the RS485 operating mode, but 
I think it is a very important feature in embedded systems. (Originally 
only the crisv10.c and atmel_serial.c driver supported the RS-485, but 
now I've modified the Freescale mxs-auart.c driver to support RS-485 too.)

There is no toolset for setting the RS-485 options in these drivers, the 
necessary ioctl calls are handled in the application C code, but I'm 
think it can be useful if we can setup and check this with stty from 
command line.

This stty functions was tesed on my Armadeus (Freescale iMX28) board, 
You can have look how this new options works: 
http://www.armadeus.com/wiki/index.php?ti

Re: [PATCH] BusyBox 1.19.4 + 1.21.0 stty add RS485 config options

walter harms — 2013-05-18T13:52:50


Am 17.05.2013 18:25, schrieb Denys Vlasenko:

hi Denys, just a comment

We are using rs485 in out embedded device too. I am not aware that there are special
rs485 commands. rs485 is used in dataaquisition devices It would make sense to include
it into the stty cmd. NTL i would suggest a special RS485 section for that.

re,
 wh

Re: [PATCH] BusyBox 1.19.4 + 1.21.0 stty add RS485 config options

Denys Vlasenko — 2013-05-17T16:25:43

You are adding rs-485 support to stty.
Are you sending patches to coreutils' stty too?
Are they accepted?

If coreutils stty doesn't have these options,
I wonder now used of "standard" tools set rs-485 parameters -
which tool they are using?

Re: Patch for udhcpc hwtype

Denys Vlasenko — 2013-05-17T13:29:09

Yes, looks like it should be.
Fixed in git.
Thanks!

Re: Compiling using LLVM Clang : Nested functions

Denys Vlasenko — 2013-05-16T16:37:50

On Thu, May 16, 2013 at 6:07 PM, Denys Vlasenko
<vda.linux< at >googlemail.com> wrote:

I committed a different version. Please try current git.

Re: Compiling using LLVM Clang : Nested functions

Denys Vlasenko — 2013-05-16T16:07:08

2013/5/16 Sam Liddicott <sam< at >liddicott.com>:

Mine does:

function                                             old     new   delta
parse_params                                        1459    2640   +1181
static.alloc_action                                   98       -     -98
------------------------------------------------------------------------------
(add/remove: 0/1 grow/shrink: 1/0 up/down: 1181/-98)         Total: 1083 bytes

Re: Compiling using LLVM Clang : Nested functions

Sam Liddicott — 2013-05-16T15:40:11

_______________________________________________
busybox mailing list
busybox< at >busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Compiling using LLVM Clang : Nested functions

Benjamin Lee — 2013-05-15T12:07:30

Dear all, a quick question...

While trying to compile the latest busybox git version using clang
3.2-2+b1, I quickly discovered a nested function in the code...
apparently the only one. ;-) See below.

My question is... does anyone know how much bigger (approximately) the
code is without such a nested function?

Thanks in advance.

Cheers! :-)
Ben.

-       /* This is the only place in busybox where we use nested function.
-        * So far more standard alternatives were bigger. */
-       /* Auto decl suppresses "func without a prototype" warning: */
-       auto action* alloc_action(int sizeof_struct, action_fp f);
-       action* alloc_action(int sizeof_struct, action_fp f)
-       {
-               action *ap;
-               appp[cur_group] = xrealloc(appp[cur_group], (cur_action+2) * sizeof(*appp));
-               appp[cur_group][cur_action++] = ap = xzalloc(sizeof_struct);
-               appp[cur_group][cur_action] = NULL;
-               ap->f = f;
-               IF_FEATURE_FIND_NOT( ap->invert

Re: [PATCH 1/1] grep: fix grep -x to not set REG_NOSUB

Denys Vlasenko — 2013-05-16T12:48:46

Applied, thanks!

Re: [PATCH] Support for '-v' argument for gzip and bzip2

Bartosz Gołaszewski — 2013-05-16T09:07:18

2013/5/15 Denys Vlasenko <vda.linux< at >googlemail.com>:

My personal reason for wanting to have this included is a script I
have to port to a busybox-based system. This script greps through a
text file (hence the patch for bug 4520 I have submitted) and requires
verbose output from gzip and bzip2 for statistical purposes i.e. to
estimate the percentage of saved space.

Nevertheless, it's also marked as TODO in archival/grep.c, so I
thought it would be useful.

Best Regards,
Bartosz Gołaszewski

Re: "mdev: remove undocumented subsystem/devname matching hack" disaster.

Piotr Karbowski — 2013-05-15T15:18:27

Denys, its awesome.

Works flawless and now I can drop some rules like event[0-9]* =input/ 
because mdev will already put it into input subdir. Thanks.