Re: AW: Re busybox tar hidden filename exploit
The underlying root problem here is the same as SQL injection or HTML cross-site scripting attacks. You have data, and you emit it in a context that is expecting a language/protocol of some sort, not raw data. You then need to escape anything in your data that could be misinterpreted as the protocol. We're really lucky that there isn't any way to make a TTY execute commands or delete files or grant user permissions. The terminal is controlled by control characters. When rendering user data for display on a terminal, the only control character that should ever pass-through from un-trusted data is "\n", and maybe "\t". All others have the potential to break the rendering on the terminal in undesirable ways. The "right solution" is to check whether output is to a TTY, and if so, escape all control chars other than ["\n","\t"] in some readable format. If the output is going to a pipe, then it should not get escaped and it is the pipe reader's responsibility to escape the data if *it* is the one emitting to a TTY (or never, if the data never reaches a TTY). A busybox-style solution might be to make a generic print function that triggers a TTY-check and caches that flag in a global variable, and then escapes all control characters other than "\n" and "\t" if it is a TTY... and probably a feature flag that makes the new print function an alias for the normal one if disabled. Then review every single utility that takes un-trusted data and use this new print function instead of the normal one. You'll run into ambiguity with things like 'cat', where people might reasonably take pre-rendered TTY protocol and want it to pass through unchanged. But with 'tar', it's fairly certain that none of the file names being read from the archive should ever be treated as pre-rendered TTY. -Mike C. On 7/2/24 11:39 AM, Walter Harms wrote: Hello, to get rid of the char set problem, i would go for a switch that forces ASCII (that is what i mean with strict ASCII-only policy). Allow only printable and force the rest to something like "\0x01" (or "?" but this may cause other problems). It should be doable, do not spend to much time with "properly", (i mean ls has a compareable feature for hidden characters in file names). Feel free to send a prototype patch, the people on the list will poke it until it is ready. good luck Von: Ian Norton Gesendet: Donnerstag, 27. Juni 2024 20:31:24 An: Walter Harms; busybox@busybox.net Betreff: Re: Re busybox tar hidden filename exploit Looking at header_list() and header_verbose_list(). Fixing it _properly_ would include some awareness of the current charset and terminal type I think. At the very least I guess we could transform all the escape chars and feed chars to a “?” maybe? From: busybox on behalf of Ian Norton Date: Tuesday, 25 June 2024 at 08:40 To: Walter Harms , busybox@busybox.net Subject: [EXTERNAL] Re: Re busybox tar hidden filename exploit Hi Walter, I had a brief look at if I could submit a patch, but I’m very very new to the busybox codebase. It appears that the same functions used to print the filenames to stdout are also shared by a number of other busybox modules. I _think_ Hi Walter, I had a brief look at if I could submit a patch, but I’m very very new to the busybox codebase. It appears that the same functions used to print the filenames to stdout are also shared by a number of other busybox modules. I _think_ that the cpio tool has the same flaw. Something that would escape any non-ascii would have been my first instinct too though perhaps that would not work so well on non 8-bit charsets. Ian From: Walter Harms Date: Monday, 24 June 2024 at 09:04 To: Ian Norton , busybox@busybox.net Subject: [EXTERNAL] AW: Re busybox tar hidden filename exploit Hi Ian, thx for the report. yes, i did not notice (and yes i check tars with -vt before installing). what do you expect now ? Do you have patch ? Do you want to start a discussion about possible solution ? (I use a strict ASCII-only policy Hi Ian, thx for the report. yes, i did not notice (and yes i check tars with -vt before installing). what do you expect now ? Do you have patch ? Do you want to start a discussion about possible solution ? (I use a strict ASCII-only policy in my projects to catch other traps also). What does gnutar do here ? CU Von: busybox im Auftrag von Ian Norton Gesendet: Donnerstag, 13. Juni 2024 19:35:33 An: busybox@busybox.net Betreff: Re busybox tar hidden filename exploit Hello all. A few weeks back I logged https://urldefense.com/v3/__https://bugs.busybox.net/show_bug.cgi?id=16018__;!!FJ-Y8qCqXTj2!dJ1sS5tgZwT81bEY9M83tem-KWln2_zEMbQ9EzMKX89APlTx7LPOsxyNcm-tWCe9LfGKR4DgVS06NXE$
Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?
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
Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?
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. 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. I would expect this all goes into the kernel's own hashing inside the RNG and so gzip or any other hash function before delivering it to the kernel is probably irrelevant. The name of the game is to find actually random bits, which you either need to save from the previous boot, or obtain from hardware somehow. The low bits of thermal sensors and multithreading scheduler timing nanoseconds are probably your best bet if you can't rely on having a hardware entropy generator. -Mike C ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox init returns fails with error code -1 (0x00007f00)
On 10/25/22 16:55, samuel ammonius wrote: Hello, I have a simple ISO filesystem set up with busybox and grub.These are the commands I use in GRUB2 to start the system: grub> set root=(cd) grub> linux /boot/bzImage root=/dev/sda1 grub> initrd /boot/initrd grub> boot I don't know how to get the full kernel error log, but the final error is "kernel panic: attempted to kill init! error code: 0x7f00". I tried building a static "Hello, world!" program as the FAQ said, and it worked. What could be causing the error? You didn't provide any details about what is inside the initrd or the filesystem, where they came from, or what process you used to create them, so the problem could be just about anything. There isn't even enough here to know whether it was busybox's init that died or the script inside the initrd. Is busybox inside the initrd? or on /dev/sda1? or both? Chances are, you should probably ask on the forum/list related to the instructions you are following, such as buildroot. If you can narrow it down to knowing for sure that busybox's init got called, and that calling other busybox applets (like '/bin/date', assuming that is one of your applets) succeeds, and give us any lines of error message that these generated before the kernel panic, and show us the /etc/inittab, then we can help a lot more accurately. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2] seedrng: limit poolsize to 256 bytes and document flock() and fsync() usage
On 5/2/22 09:54, Bernhard Reutner-Fischer wrote: There is also the case (that on my systems at least) udev initialisation reads from /dev/[u]random well before the S20 script loads any saved entropy. I've not tried to find out what the value is used for. I find at least one occurrence where the goal is to create a random delay in udev-watch.c [1]. Yes, but that spot does seem to have a fallback. But why is the seeding being run only at S20, way after udev? It needs to be at least late enough for the persistent storage to be mounted, which probably isn't the root filesystem at boot. udev probably needs to run first to find the device nodes for the persistent storage. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: suspected bug in timeout command
On 3/2/22 02:45, Raffaello D. Di Napoli wrote: On 3/1/22 16:57, Denys Vlasenko wrote: On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko wrote: Meanwhile: what "timeout" is doing is it tries to get out of the way of the PROG to be launched so that timeout's parent sees PROG (not timeout) as a child. E.g. it can send signals to it, get waitpid notifications if PROG has been stopped with a signal, and such. And PROG also has no spurious "timeout" child. "timeout" exists as an orphaned granchild. That doesn’t seem to be a concern for coreutils, according to Rob’s inspection. (I haven’t looked, but I’ll assume they still do signal forwarding and everything that can be done cheaply.) Isn’t it a goal of BB to avoid unnecessary divergence from coreutils? Let's go with a solution with fd opened to /proc/PID? I’d think simplifying the implementation and bringing it closer to coreutils’ would be more in line with BB’s goals, instead of making it larger and more complicated (especially considering how counter-intuitive it is already, despite being fairly small). It might be worth mentioning that busybox can't conform to coreutils unless it does remain the parent process, because of this detail: (from coreutils' timeout man page) > If the command times out, and --preserve-status is not set, then > exit with status 124. Otherwise, exit with the status of COMMAND. timeout doesn't appear to be part of POSIX, though. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: grep: add option for better usability in pipelines
On 2/16/22 19:32, Kang-Che Sung wrote: Now, for an example where it makes a difference. Consider a Bash script like this: # enable automatic error handling set -eo pipefail # check for string "issues" in a logfile cat logfile | grep issue | sort --unique If there are no issues in the logs, grep return exit code 1 and the shell interprets this as an error and exits itself. Why do we need to implement a workaround in grep while you can do this in shell to ignore the exit code of grep? { grep issue In order to implement his suggestion, you need to only ignore exit code 1, while still allowing other exit codes to abort the script. (like a system error while reading the file) But also, I've never seen ":" used as a command... where is that documented? Is it equivalent to 'true'? -Mike C ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: suspected bug in timeout command
On 2/12/22 07:38, Michael Conrad wrote: Correctly using pidfd *still* requires that you be the parent process, else the child could get reaped and replaced before the pidfd is created. As far as I can tell, the only purpose of pidfd is for waking on poll() instead of using signals, which is orthagonal to this problem. I haven't looked at the source in busybox yet, but it boggles my mind that it wouldn't just be a simple fork+alarm+waitpid because that is literally the least code implementation, and race-free. -Mike C Sorry for being lazy. I looked at the source and this is the reason: /* We want to create a grandchild which will watch * and kill the grandparent. Other methods: * making parent watch child disrupts parent<->child link * (example: "tcpsvd 0.0.0.0 1234 timeout service_prog" - * it's better if service_prog is a child of tcpsvd!), * making child watch parent results in programs having * unexpected children. */ I don't follow this reasoning. Does "disrupts the parent<->child link" just about sending signals? If the timeout app relays all signals from itself to the child, what remaining problems would exist? -Mike C ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: suspected bug in timeout command
On 2/12/22 06:08, David Laight wrote: From: Raffaello D. Di Napoli Sent: 12 February 2022 01:33 On 2/11/22 16:22, Rob Landley wrote: On 2/9/22 11:12 AM, Baruch Siach wrote: Hi Sun, On Wed, Feb 09 2022, סאן עמר wrote: Hi, I'm using busybox for a while now (v1.29.2). and I had an issue with a sigterm send randomly to a process of mine. I debugged it until I found it from the timeout process which was assigned before to another process with the same pid. (i'm using a lot of timeouts for a lot of jobs) so i looked at the code, "timeout.c" file where it sleep for 1 second in each iteration then check the timeout status. I suspect at this time the process timeout monitoring is terminated, but another one with the same pid is already created. which creates unwanted timeout. There is a comment in there about sleep for "HUGE NUM" will probably result in this issue, but I can't see why it won't occur also in the current case. there is no change of this behaviour in the latest master. i would appreciate any help, sun. Any reference to PID number is inherently racy. Not between parent and child. Except in BB’s timeout, the relationship is not parent/child :) Much to my surprise, I’ll say that. When I read the bug report the other day, I thought to myself well, this one ought to be easy to fix. But no, there’s no SIGCHLD to be handled, no relationship between processes to be leveraged. I don’t think this bug can be fixed without a near-complete rewrite, or without doing a lot of procfs digging to really validate the waited-on process, since kill(pid, 0) only validates a pid, not a process. And Linux uses a strict 'next free pid' algorithm for new processes so the is no guard time between a process exiting and its pid being reused. This problem was 'fixed' inside the kernel by using a small structure instead of the pid itself - but that didn't help userspace (or even some drivers). By comparison NetBSD uses the high bits of the pid as a 'generation number' and so guarantees that a pid won't be reused for some time (a few thousand forks). You can use the process start time (I think it is in /proc/pid/stat) to validate the process just before the kill(). That leaves a very small timing window that it is hard to avoid without using pidfd. David Correctly using pidfd *still* requires that you be the parent process, else the child could get reaped and replaced before the pidfd is created. As far as I can tell, the only purpose of pidfd is for waking on poll() instead of using signals, which is orthagonal to this problem. I haven't looked at the source in busybox yet, but it boggles my mind that it wouldn't just be a simple fork+alarm+waitpid because that is literally the least code implementation, and race-free. -Mike C ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: suspected bug in timeout command
On 2/9/22 12:12, Baruch Siach wrote: Hi Sun, On Wed, Feb 09 2022, סאן עמר wrote: Hi, I'm using busybox for a while now (v1.29.2). and I had an issue with a sigterm send randomly to a process of mine. I debugged it until I found it from the timeout process which was assigned before to another process with the same pid. (i'm using a lot of timeouts for a lot of jobs) so i looked at the code, "timeout.c" file where it sleep for 1 second in each iteration then check the timeout status. I suspect at this time the process timeout monitoring is terminated, but another one with the same pid is already created. which creates unwanted timeout. There is a comment in there about sleep for "HUGE NUM" will probably result in this issue, but I can't see why it won't occur also in the current case. there is no change of this behaviour in the latest master. i would appreciate any help, sun. Any reference to PID number is inherently racy. There is no solution for your problem in the traditional POSIX API. PIDs are not racy if they are sent by the parent process. Since the timeout command starts the other command, and waits to kill it, it should be the parent process, and will always reliably know that either the child is not reaped and can be sent a signal, or that it is reaped and there's no reason to. Perhaps the implementation of this command needs corrected? -Mike C ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Tar component in busybox version 1.34.1 has a memory leak bug when trying to unpack a tar file.
On 12/1/21 7:42 AM, tito wrote: It can matter: consider large tar files on memory constrained devices. tar may fail to complete correctly, due to running out of memory, and in the process of running out of memory, may invoke the OOM killer in the process, which might kill some other process. Ariadne Hi, // Die if we can't allocate size bytes of memory. void* FAST_FUNC xmalloc(size_t size) { void *ptr = malloc(size); if (ptr == NULL && size != 0) bb_die_memory_exhausted(); return ptr; } Ciao, Tito A stock Linux system will happily slaughter your system services with the OOM killer before malloc ever returns NULL. In fact, I think the only way I've ever seen a program get NULL from malloc is if it exhausts 32-bit address space. But, anyone assembling a embedded system has to be aware of the proper way to configure the OOM killer to kill the correct things first, so tar shouldn't be running with any privileges that would cause a real problem. But back to the original question, Hi~ It seems that I found a bug on busybox version 1.34.1: In libbb/xfuncs_printf.c:50, malloc twice for archive_handle and archive_hadle->fileheader with 184 and 72 bytes heap space. Back to tar_main function, the two pointers(tar_handle,tar_handle->file_header) hasn't been freed when return. This isn't a bug. Busybox frequently leaves out the 'free()' operations for anything that is a one-time allocation for the life of the process, because freeing it does nothing more than take up space and time. Memory allocation tools will produce lots of errors when you use them on busybox. It only needs fixed if the memory usage *grows un-bounded* during execution. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] shrink last_char_is function even more
On 7/19/2020 2:48 PM, Denys Vlasenko wrote: strrchr(s,c) will first find the end of s, then go backwards looking for c. The second part is wasted work, we only need to check the*last* char == c. Maybe a naive implementation, but why wouldn't they just record the last occurrence on a forward scan? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 3/4] lsscsi: code shrink and refactor
On 7/9/2020 3:16 PM, Markus Gothe wrote: Jon Postel formulated the robustness principle decades ago. Still today it is a good advice to "be liberal in what you accept and strict in what you send". Counterexample: Internet Explorer It allowed so much garbage to render correctly that other browser vendors had to work overtime to accept all the same garbage and make sure it rendered in the same way. Then, subsequently when IE was no longer defining the standard, progress was hamstrung by needing to be compatible with its own past allowances lest they be accused of breaking people intranets. So much so that they just weren't able to fix most of their bugs and eventually abandoned the project. If they had just declared tighter standards and enforced the rules, web development might not have been a misery for an entire decade. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Nuke
On 6/20/2020 10:55 PM, Eli Schwartz wrote: you should not "happen" to type in suspicious arguments to commands you don't understand I'd say about twice a year I accidentally dump some large body of text into my shell by accident. The idea that one of those lines of text might start with the word nuke is unsettling, so I checked all my linux systems and verified that none of them have nuke in the path. So if no standard system includes nuke by default maybe good to drop from default in busybox? -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox with a UEFI bios?
Busybox shouldn't have anything to do with BIOS or UEFI. The boot loader and kernel handle those things, then once the kernel is running Busybox has a standard Posix environment to operate in. You should investigate documentation on UEFI for the boot loader you are using. On 5/4/2020 4:10 AM, Nikos Mouzakitis wrote: Hello, i have used BusyBox with SeaBIOS as a BIOS and i have successfully launched it. What are the steps that i should take to do it with a UEFI bios? For example with firmware from TianoCore/EDK2? 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] nslookup: skip line comments on parsing /etc/resolv.conf
On 4/22/2020 11:36 AM, Leesoo Ahn wrote: hence we save a few cycles while parsing But you are also suggesting adding bytes, right? This is the second time you have proposed a patch that adds bulk to busybox to save a little performance at runtime, which is the opposite of the goal of the project. If you have use cases that are actually impacted by these performance problems, then you need to make a much more thorough argument about why these extra bytes are needed. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: git smart http for busybox repo
On 4/13/2020 11:31 AM, Eli Schwartz wrote: by attempting to demonize the request as an attack from people demanding a workflow change from mailing lists and git to "mandatory github webflow omg so smart". I think he was serious, actually. A rare case of needing to turn *off* your sarcasm filter, maybe? FWIW, GitLab is available for free to run on your own infrastructure, and if you run it in a docker container behind Traefik, it gets an automatic LetsEncrypt SSL certificate. It's amazingly easy to buy a $10/mo Linode or Digital Ocean Droplet and have a full-featured source repository website in the space of a Saturday afternoon. (you can get it working on a $5/mo VM if you replace systemd with busybox service management) I am not suggesting that this project change workflow at all, I just want to bring these "current events" to everyone's attention, to help put wdlkmpx's comments into perspective. -Mike C ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Weird signal issues using yocto's warrior busybox (aarch64) when memory is cached
On 1/30/2020 12:53 AM, Sergio Paracuellos wrote: warning: core file may not match specified executable file. [New LWP 23217] warning: Could not load shared library symbols for 3 libraries, e.g. /lib/libm.so.6. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `sleep 1'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xfcd7fc60 in ?? () (gdb) bt #0 0xfcd7fc60 in ?? () #1 0x00555668af74 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) Look at the PC (0xfcd7fc60) at this point.. It has not sense at all. For me it looks like a stack corruption. First things first, do you trust the hardware? If the system swapped out some pages and then read them back in and the controller or storage device gave back bad data, this could cause all sorts of crashes. Maybe run a memtest, too, unless you can reproduce the issue on multiple different machines. I just had a USB thumb drive corrupt a file with no warning, so it was fresh on my mind. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Why almost every command is trying to read urandom?
On 11/12/19 2:47 PM, Mauro Condarelli wrote: In a recent kernel(5.x) / Buildroot / Busybox for an embedded system (mips/MT7628, if it matters) I see TONS of: |random: mount: uninitialized urandom read (4 bytes read) random: fsck.vfat: uninitialized urandom read (4 bytes read) random: tar: uninitialized urandom read (4 bytes read) (Complete startup log below) | I hadn't noticed before, but I just checked and my busybox 1.11 is doing this (reading /dev/urandom on every single applet startup) but I have a later busybox 1.30 which does not. strace busybox echo 2>&1 | grep rand This stops when, after a while (up to 10min later!!) I finally see: |[ 562.001438] random: crng init done | Two questions: 1. why does it take so long to initialize /dev/urandom? 2. for what reason |mount| or |tar| should try to use it in the first place? Note: I did NOT have this problem with older kernels (3.x). 1. /dev/random needs to "collect entropy" from unpredictable things like scheduler timing, human input devices, etc. /dev/urandom is then a less-secure source of random which gets initialized from /dev/random once the kernel is confident that /dev/random is random enough. There are various places throughout the kernel code that feed entropy into the random pool, so changing kernels can change how fast it initializes. Busybox doesn't really have anything to do with this. There might be some kernel options you need to explore to get things to initialize faster; but making it initialize faster might also be less secure. You also have the option of writing some init script to preserve entropy from the previous boot and seed it after the reboot (by writing to /dev/random) 2. For one of the copies of busybox I have on hand, it appears that it initializes srand() at the startup of every single applet. I don't see a reference to /dev/urandom in the current busybox source that would have this effect, so either busybox fixed it, or the behavior was coming from a particular libc used to build busybox. My busybox with that behavior is statically linked, and I don't recall which libc it was. Since you just got yours out of a Buildroot, you should be able to investigate that easier. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] libbb: Converted safe_read to safe_write format
On 10/18/2019 10:54 AM, Denys Vlasenko wrote: On Thu, Oct 10, 2019 at 4:35 PM Martin Lewis wrote: Hello, Could you please elaborate on what was lacking in the INT_MAX part? As seen in write's man page: On Linux, write() (and similar system calls) will transfer at most 0x7000 (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is true on both 32-bit and 64-bit systems.) Wouldn't it create an issue with 64 bit systems when trying to read/write large files? This seemed like a change not prompted by an actually observed buggy behavior. In fact, to my eyes +if (count > SYS_BUFSIZE_MAX) +count = SYS_BUFSIZE_MAX; looks like it *introduces* a bug. read() is always allowed to return a short count however the kernel pleases, and safe_read is supposed to call it in a loop until the desired size is reached or until EOF or a fatal error. If you truncate the count before beginning the loop, then the caller ends up with a short read even though there might be more data. (not that anyone would likely have a reason to *require* more than 2GB in a single buffer anyway...) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: fdisk head inconsistency
On 10/1/2019 6:58 PM, Mauro Condarelli wrote: The former consistently swears I have "Geometry: 245 heads, 62 sectors/track, 1021 cylinders", while the latter insists on "Geometry: 4 heads, 16 sectors/track, 242560 cylinders". Physically the *same* card. Of course Debian Linux is accessing the card through a USB card reader (hama a4504143, if it matters), while embedded Linux is accessing it directly via MMC interface present on uController (MT7628)... which could be a significant difference. I just tried two versions of busybox fdisk (1.19.0, and 1.30.1) vs. two versions of util-linux fdisk (2.19, 2.34) and all four tools agree about the drive geometry of any drive I've tested on. I think you'll just need to do more experiments and see if you can pin down the problem on your end. I need to do this in a script and to use BB fdisk I need to print previous partition data and manually set start of next one to prev_end+1. This is "inconvenient" to do in a shell script. IMHO one of the two programs is severely broken and I would like to understand which and how to fix it. Right now my "solution" is to disable BB fdisk and to install util-linux one, but that, of course, has a cost in a severely constrained embedded system with 16M total Flash space. Any advice welcome. Very inconvenient to do in a shell script, I agree :-) and in fact I'd advise against parsing fdisk with a shell at all. The four tools I just tested each had a different output format! That's a pretty good indication it could change in the future and break your script and blow away someone's data. Also that 'bootable' flag is pretty annoying because its presence/absence changes the number of fields on the line. There's an "sfdisk" which is better for scripting, but no busybox applet for it. Still, it is safer than scripting input for fdisk. You don't need to give CHS geometry to fdisk, just sector numbers. You can get sector numbers direct from the kernel using /sys/class/block/$DEV/start and /sys/class/block/$DEV/size. (or on old kernels, /sys/block/$DEV/$PART_DEV/{start,size} ). You could then construct a script for fdisk and pipe that in. Of course, this depends on the kernel having read the partition table, which might not be the case if you're formatting something from scratch, but there's 'partprobe' for that. You also have to worry about what kind of partition table it is, because the kernel can parse GPT partitions and then if you try forcibly adding a new one with fdisk it might blow away the GPT table. I just checked, and 'gdisk' isn't available from busybox yet... so there might not be a safe way to do this with pure busybox tools. Hope that helps. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: fdisk head inconsistency
On 9/29/2019 8:57 AM, Mauro Condarelli wrote: Note: the SD card was originally formatted using Debian GNU/Linux fdisk on a desktop. I have several problems here, possibly all stemming from a bogus detection of "disk geometry": - (n)ew partition always suggested sector 16 as starting point (obviously useless). - (p)rint shows bogus values in CHS of newly created Partitions. - (v)erify complains about "old" partition geometry. (snip) Command (m for help): p Disk /dev/mmcblk0: 7580 MB, 7948206080 bytes, 15523840 sectors 242560 cylinders, 4 heads, 16 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 0,33,3 17,96,10 2048 264191 262144 128M c Win95 FAT32 (LBA) /dev/mmcblk0p2 17,96,11 293,126,14 264192 4458495 4194304 2048M 83 Linux Since you have only run "delete" commands prior to this print command, I'm assuming that the debian fdisk wrote out those partitions where the head number (i.e. 33) is exceeding the maximum (4). (but maybe you could check?) I would guess that maybe the USB stick came with the partition table listing 4 heads 16 sectors as a hint to partition tools that the media likes 32K boundaries (4*16*512=32768). Maybe Debian fdisk ignored those and wrote out CHS offsets based on assumption that the partition table matches the default geometry that fdisk generates? Either way, I'm guessing the inconsistency is already written to disk, so you can fix it (or not) however you like. In the grand scheme of things, no modern software cares about those CHS numbers anyway. Each partition table entry contains redundant CHS start/end and LBA (plain old integer sector number) start/end, and every modern tool/OS uses the LBA number and ignores the CHS, because the CHS haven't been real measurements for 25 years or more. https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries The only thing you should worry about is that the partition is aligned on a multiple of the erase-size of the USB media. I'm not current on what those are, but 1MiB should be sufficient, which is why the default start sector for fdisk is 2048 (*512=1MiB) I'd just go ahead and try it assuming you have all the data on there backed up, which you should any time you play with partition tables ;-) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: in initrd "exec sh /dev/console 2>&1" does not respond to keyboard
Well, just a guess, but I'd say your problem is with kernel device drivers for input. Usually people have the basic text showing up on their console and the complaints are about how to get ^C and other tty-specific features to work while using /dev/console. Your problem sounds more like the Linux virtual console subsystem isn't connecting to your input devices. I'd suggest poking around in the input drivers section of the config and make sure things are compiled as "=y" and not as modules. On 2/27/2019 8:44 PM, David Mathog wrote: On 27-Feb-2019 17:37, Michael Conrad wrote: On 2/27/2019 6:00 PM, David Mathog wrote: On 27-Feb-2019 14:01, David Mathog wrote: This is really frustrating! Perhaps there is some kernel parameter for 3.10.108 kernels which needs to be set (or unset)??? These are built into the kernel, seems like they should be enough CONFIG_HID=y CONFIG_HID_GENERIC=y CONFIG_USB_HID=y CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB=y It is definitely the kernel. If the custom (based on "make menuconfig" of boel) 3.10.108 kernel is replaced with a stock Centos 7 kernel then What do you get from "grep CONSOLE .config" in each of the two kernels ? The one where the keyboard does not work: # CONFIG_NETCONSOLE is not set CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y The one where where the keyboard does work: CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_CONSOLE_POLL=y # CONFIG_LP_CONSOLE is not set CONFIG_VIRTIO_CONSOLE=m CONFIG_VGA_CONSOLE=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_USB_SERIAL_CONSOLE=y # CONFIG_PSTORE_CONSOLE is not set CONFIG_KGDB_SERIAL_CONSOLE=y That said, there are a zillion other differences... Thanks, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ 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: in initrd "exec sh /dev/console 2>&1" does not respond to keyboard
On 2/27/2019 6:00 PM, David Mathog wrote: On 27-Feb-2019 14:01, David Mathog wrote: This is really frustrating! Perhaps there is some kernel parameter for 3.10.108 kernels which needs to be set (or unset)??? These are built into the kernel, seems like they should be enough CONFIG_HID=y CONFIG_HID_GENERIC=y CONFIG_USB_HID=y CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB=y It is definitely the kernel. If the custom (based on "make menuconfig" of boel) 3.10.108 kernel is replaced with a stock Centos 7 kernel then What do you get from "grep CONSOLE .config" in each of the two kernels ? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [git commit] bc: new applet, throws warning
On 12/6/2018 11:48 AM, Gavin Howard wrote: you are going to have to make the bc not give good error messages and/or not check for errors as thoroughly (a massive chunk of the parser, which is the largest portion, is dedicated to error checking), reduce the quality of the code, reduce the performance of the math (though this would not remove much), or all of them combined. Just FYI, these are typical things people do for busybox applets ;-) I'm not a bc user, so I don't care either way; having the applet seems better than not having it, and you seem to have thoroughly completed a difficult project. ...but I do think maybe you missed the spirit of Busybox code. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC PATCH v2] Allow applets to be implemented as scripts
On 11/7/2018 9:18 AM, Kang-Che Sung wrote: On Wed, Nov 7, 2018 at 9:54 PM Tito wrote: this embedded scripts patch looks like "featuritis" at its best to me. It is adding complexity for solving what problem exactly: avoiding to copy the scripts manually to the new system or to the new firmware image? I see one advantage of embedding scripts into busybox binary: compression. The script could remain compressed in a firmware or read-only image, saving space, and is useful for users who build busybox only to run a specific script (installation, embedded system startup, or something else non-trivial). I think it's okay for that use case. IMHO squashfs is a better option all around. The main use case I imagine is that you want a recovery shell to live alongside a regular system image, and have the embedded scripts only available when running busybox sh, and save some integration work of mounting the rest of the recovery file tree at the appropriate places. For example, if your /etc/profile is only valid for bash, then if you want to run busybox ash on that system it would help to have /etc/profile load magically from within busybox. The main downside I see is that it violates the Principle of Least Astonishment. One side effect I fear will derive from this patch is that users which would be capable of sending patches for bugs they find in bb will resort to simply scrap the applet and add an embedded script as it is faster. I disagree. Embedded script always has an overhead of starting a shell interpreter, although I acknowledge the size advantage the script can provide, as long as many coreutils are present in that environment. The script won't worth embedding if you don't intend to build a shell or coreutils in busybox. It sounds like not just the overhead of the interpreter, but also the overhead of decompressing them on each execution. But, there are lots of standard unix tools which are seldom-used and don't have much performance requirement, and if they can be implemented as a shell script half the size of the comparable machine code, then that makes sense. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: License concerns when embedding script in busybox binary
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... -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: less Idle time with busybox ash as bash vs bash
Busybox utilities are written in whatever way uses the fewest bytes. Most standard utilities are optimized for speed. Sometimes the reduced footprint of busybox can offset the lack of speed optimization because it can remain in disk cache or processor cache. And sometimes not. If your bash script does a lot of script logic (i.e. more of an application rather than just sequence of commands), then it would be reasonable to see a dip in performance. If you do mostly just call other utilities, then you should make sure that you have PREFER_APPLETS enabled and that you're actually getting the benefit of avoiding exec(). Maybe, try running strace on each of bash and ash-as-bash and count the number of execve calls. Then you'll have a decent idea of how the bash builtins stack up to the busybox PREFER_APPLETS overall. On 9/6/2018 6:54 PM, James Hanley wrote: To be clear - when we run the same script under bash vs busybox ash as bash - bash yields 10% more idle time to the system. I assumed that the fork/exec of all the underlying utilities (test etc) compared to the vfork or function calls in busybox would yield better results (not worse) then bash. Is this expected behavior? -Jim On Aug 31, 2018, at 2:06 PM, 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: [PATCH] wget: don't silently ignore certificate validation
The story just broke earlier this year how a casino hotel "smart thermometer" in the fish tank was used as a backdoor to attack the rest of their network. If a smart device running busybox is programmed to automatically check for firmware updates, the designers might expect HTTPS to be a valid form of security to know that they were accessing their own servers. If they don't write a test case to verify that certificates are checked, it's shoddy work, but there's a lot of shoddy work in smart devices. In such a scenario, anyone on the same wifi would be able to overwrite the firmware of the device. This almost deserves a CVE number. -Mike On 5/26/2018 1:34 PM, Denys Vlasenko wrote: wget should work for common use cases. Such as downloading sources of kernels, gcc and such. From build scripts, not only by hand. Without having to modify said scripts. Your patch breaks that. NAK. I don't care that security people are upset. They are paranoid, it's part of their profession. It does not mean everybody else have to be as paranoid. If you have a patch which adds actual cert checking and thus does not introduce regressions, please post it. On Sat, May 26, 2018 at 6:38 PM, wrote: //config: If you still think this is unacceptable, send patches. That’s exactly what I did. http://lists.busybox.net/pipermail/busybox/2018-May/086444.html Jakub On 2018-05-26 17:54, Denys Vlasenko wrote: On Sat, May 26, 2018 at 5:39 PM, wrote: That's a crime against security! Say what? That’s a hyperbole. The thing is that when you don’t verify the peer’s certificate, then you’re vulnerable to MitM attack with fake certificate injection. The whole SSL/TLS is totally useless in that moment. It’s more or less like putting the door’s key under the carpet right in front of the door. Allowing to bypass/ignore certificate verification is ok-ish in some situations, but only when the user do it consciously, using explicit option such as --no-check-certificate, not silently as the default option. wget.c: //config: If you still think this is unacceptable, send patches. //config: //config: If you still think this is unacceptable, do not want to send //config: patches, but do want to waste bandwidth explaining how wrong //config: it is, you will be ignored. ___ 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: add bb_info_msg was Re: Applets send errors to syslog during normal, successful operation
On 3/5/2018 5:11 PM, Deweloper wrote: Hi, I see your point, forget about this bb_info_msg stuff. The same result can still be achieved by using: syslog_level = LOG_INFO bb_error_msg(...) syslog_level = LOG_ERR if needed If I interpret bloatcheck results properly, the above costs extra 45 B of code per call @x86-64. That sounded suspicious, so I checked. Might be worthwhile investigating what gcc was up to, because assigning a small constant to a global should be 7 bytes each on x86-64 However, pushing a small constant onto the stack should be 2 bytes, though ironically loading that small constant into a register for pass-by-register calling convention is 5. So, with enough calls it would be worth it to create a new function, with a savings of about 9 bytes per use over the global variable trick vs. the cost of adding the new function. (and wow, there's a nutty size optimization ... you could push a 1-byte constant onto the stack and pop it off into the register of your choice with two fewer bytes than the instruction to assign the constant directly to the register.) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Proper defense against symlink attacks in tar, unzip et al
On 2/19/2018 11:15 AM, Denys Vlasenko wrote: On Mon, Feb 19, 2018 at 5:09 PM, Harald van Dijk wrote: Let's also brainstorm option 3: Allow symlinks which (a) start with one or more "../"; (b) never end up on a higher level of directory tree: "../dir/.." is ok, "../../usr/bin/.." is ok, "../file" is not ok, "../../dir/file" is not ok; and (c) they also should not leave tarred tree: symlink "sbin/mkswap" to "../bin/busybox" is ok, but symlink "mkswap" to "../bin/busybox" is not ok (it hops "above" the tree). This sounds a bit complicated, but it can be achieved just by looking at names, no multiple lstat() calls for every open() needed. With only these symlinks allowed, we know that if we untar to an empty directory or to a formerly empty directory with another tarball untarred, any pathname we open, whilst it can contain components which are symlinks, they nevertheless can not allow new opens to "leave" the tree and create files elsewhere. This wouldn't be safe, I think. Consider a tarball containing a/ b/ a/a -> ../b a/a/a -> ../../c The link to "../../c" is not allowed - it fails criteria (b). You wrote "it can be achieved just by looking at names", but that's not enough here: you have to know that a/a/a is actually b/a, so only one level deep in the -C directory, to know that ../../c points outside the -C directory. Yes... but: Since the a/a -> ../b symlink may not even be in this archive, the only way to determine that is by lstat(). I assume that tarball(s) are being unpacked into an empty directory. The case when someone already placed malicious symlinks there before unpacking would be a bug in whatever tool allowed _that_ to happen. My goal here is to not allow tar (and unzip) to create such symlinks. That might be considered a bug though. There's lots of times a symlink points to a higher directory (or even starts with '/') and tar should be a reliable way to mirror a directory tree. What if you do a test on the inode of the destination directory? To determine whether it is valid, repeatedly append ".." and stat until you reach root or the unpack directory. Then to speed it up, make a fixed-size LRU cache of directories you know are valid. Each time you create a directory, add it to the cache, and then on average you probably only add one directory stat per unpacked file. For more speed and less security, just change it to a cache of path names. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup
On 11/24/2017 9:09 PM, Deb McLemore wrote: + while (1) { + fdrc = connect(fdBB2, + (struct sockaddr *)&bb_addr2, + sizeof(sa_family_t) + + BB_SIGNALS_SOCKET_STR_LEN); + if (fdrc == 0) + break; + sleep(1); + } On 2/14/2018 1:58 PM, Michael Conrad wrote: This will give you even better "instant boot sequence abort" performance than you would get with the design you're proposing, unless you have some insanely high polling rate in the reboot_helper that you think can actually deliver the signal before init has even forked for the first time. Sorry, I wasn't paying close enough attention to what you were proposing. If you have a 1-second sleep, then you're really not trying to block the startup sequence, you're just looking for a way to make sure the signal gets delivered? ...then just /bin/reboot: #! /bin/sh while ! -d /proc; do sleep 1; done; /bin/busybox reboot ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup
On 2/14/2018 12:53 PM, Deb McLemore wrote: The only reproduction we were able to perform injected via a BMC soft poweroff being triggered. This then called into kernel/reboot.c (orderly_poweroff where the schedule_work was performed) utilizing the usermodehelper during the run_cmd /sbin/poweroff. I'd like to point out that there's still a race condition, since when init starts it might kick off the rest of your startup sequence before the idle reboot process gets a time slice to discover that init is alive and send the signal. Would it maybe be better to have the main script that initializes your system check for the existence of the socket, and if found, stop everything and tell init to shutdown? Also, why not have the reboot process look for something in the filesystem to indicate whether the system has started booting? Before init starts, there won't be anything in the filesystem, but that's not a problem because you can just wait until there is. To make a complete proposal, why not: reboot_helper: 1) create abstract socket 2) wait for any filesystem path that indicates init sequence has started (/proc maybe) 3) send reboot signal to init init_userspace.sh 1) check for abstract socket, and if exists, send signal to init and then exit 2) else run startup sequence This will give you even better "instant boot sequence abort" performance than you would get with the design you're proposing, unless you have some insanely high polling rate in the reboot_helper that you think can actually deliver the signal before init has even forked for the first time. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 1/26/2018 12:47 PM, Cathey, Jim wrote: My understanding, from years past, is that "source " (or ". ") is _exactly_ the same as "", except that it's running in _this_ shell rather than in a subshell. Thus it is able to affect environment variables that subsequent commands can inherit, etc. If "." is not in your PATH, and you want to source a file that's right there, you have to ". ./" just as you'd expect. If that's not what bash is doing, then it's wrong. I fought through the bash startup scripts almost 20 years ago in college, and still have "source .bashrc" in my ~/.bash_profile that I've been carrying from system to system ever since :-) and my PATH has never had '.' in it. Your explanation makes perfect sense though. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: make bash_source command search current directory after PATH
On 1/26/2018 9:15 AM, Denys Vlasenko wrote: On Fri, Jan 26, 2018 at 9:34 AM, Paul Otto wrote: According to the BASH documentation, the source command should: Read and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename. If filename does not contain a slash, filenames in PATH are used to find the directory containing filename. The file searched for in PATH need not be executable. When bash is not in posix mode, the current directory is searched if no file is found in PATH. I wish bash wouldn't introduce gratuitous standard violations. But wow, learn something every day... I never knew 'source' searched PATH at all. I thought it just loaded a file with the same semantics as 'open()'. This would be the danger of learning by example instead of reading the manual. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.
On 1/9/2018 1:53 PM, Laurent Bercot wrote: Zombies will _always_ be observable, even if you try to reap immediately. Of course. I used "observable" in the broad sense, meaning there is a nonzero amount of time where init is not runnable, won't be scheduled, and won't immediately reap zombies. This makes zombie observation literally millions of times more likely than when there's no blocking path between the moment it gets a SIGCHLD and the moment it reaps the zombie. :) But then there's the age-old question of whether you should make edge cases more rare so that they almost never happen, or more frequent so that people can catch their mistakes. Some years ago, I had a co-worker who was testing our code (C++) on BSD while I was testing on Linux, and he would constantly find my un-initialized attribute bugs, because Linux was zeroing every object allocation (probably just the underlying pages from mmap), but BSD wasn't. I'm sure the Linux behavior saves people from a lot of random crashes, making development easier, but it leaves the bugs out there in the wild to be run into later. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY
On 12/24/2017 4:43 AM, Ceriel Jacobs wrote: Where is the user interface to quickly issue a pre-written shell function? And how to see the available functions? ls /usr/local/bin ...? Just add your "pre-written shell commands" in script files, give them a useful name, and put them in the PATH. This is what most people do. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: BusyBox built-in shell (ash)
On 12/12/2017 6:28 PM, A.W.C. wrote: yes, I know that Squashfs is read-only filesystem. Tried again, not sure what need be changed here for this specific configuration and filesystems available. # mknod -m 666 /dev/null c 1 3 mknod: /dev/null: Read-only file system You say you understand it is read only, but this error message is exactly the problem you are having. You cannot change things in a directory which is on a read-only filesystem. It appears you do not have the devtmpfs built into your kernel (the one which comes pre-populated with lots of helpful device nodes), so you will need to use something else, like tmpfs (which comes completely empty, but writable). Maybe try mount -t tmpfs none /dev mknod -m 666 /dev/null c 1 3 # and all the rest of your device nodes -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Reboot implemention
On 11/13/2017 8:19 PM, Cathey, Jim wrote: >Is there a reason why BusyBox's [reboot] implementation is different, or is it a bug? The final fs cleanup, and the only one that really counts, is what the kernel does after init(8) exits. Pretty sure if init exits it is an immediate PANIC, which is not how most systems reboot. I think it all ends with the reboot syscall. I'm not sure what the semantics are for that syscall, but it would seem that sync() would be wise to execute first. Unless it's implied by reboot(). -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: avoid GLIBC'ism %m
On 7/22/2017 2:56 PM, Johannes Schindelin wrote: Hi Denys, On Fri, 21 Jul 2017, Denys Vlasenko wrote: On Wed, Jul 19, 2017 at 3:47 AM, Jody Bruchon wrote: On 2017-07-18 9:15 PM, Kang-Che Sung wrote: On Wed, Jul 19, 2017 at 2:11 AM, Markus Gothe wrote: Actually last time I checked ‘%m’ is POSIX contrary to glibc’s deprecated '%a’. However, I agree that it should not be used since at least uClibc can be built without support for it. How come %m is POSIX when I didn't see any mention of it in this page? http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html It does not appear to be part of POSIX or the Single UNIX Specification. The glibc man page (as of 2016-12-12) even indicates that it is a glibc-specific extension: *m *(Glibc extension; supported by uClibc and musl.) Print output of /strerror(errno)/. No argument is required. This sounds like every libc has already conceded to implementing it. Let's benefit from it then? No, not every libc. I would not have spent the time and effort to develop the patch, contribute it, rework it and contribute a second iteration if it was not for a good reason now, would I. Ciao, Johannes I believe his point is that your patch adds size to busybox which is unneeded for most users. (btw, it's recommended to post bloatcheck numbers with a patch. If you show a small number from bloatcheck then there is less to argue about) Which libc are you using? Do you think %m support could be checked with an ifdef? -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 1/1] makedevs: set path size to match linux
On 6/27/2017 3:10 AM, Ralf Friedl wrote: Michael Conrad wrote: If you ask for large enough allocations on the stack, GCC will secretly give you malloc/free instead, which adds to code size. It might be that 4096 triggers this effect, and perhaps that was the reason for the original small-ish static buffer. Do you have a reference for that? I just tried it, and GCC just allocates memory from the stack no matter the size. Granted, it is a 64-bit system, but I used 0x1 (281474976710656) which should be enough to trigger such a behavior even on a 64-bit system. In fact, it is more than a current system can provide either in the stack or through malloc. I guess I'll retract this, unless someone else knows something. I remember someone warning about this behavior, but I can't find a reference and I just tested on 32-bit and allocating stack buffers up to the maximum stack size are all shifting the stack pointer by the size of the buffer. Declaring a buffer larger than the maximum stack size results in an instant segfault when the function is called. It could have been a different compiler, or platform, or maybe a special flag to gcc. Sorry for the misinformation. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 1/1] makedevs: set path size to match linux
On 6/26/2017 9:45 PM, Matthew Weber wrote: Baruch/Emmanuel, On Mon, Jun 26, 2017 at 7:36 PM, Emmanuel Deloget wrote: Hello, On Mon, Jun 26, 2017 at 11:23 PM, Matthew Weber wrote: Baruch, On Mon, Jun 26, 2017 at 3:55 PM, Baruch Siach wrote: Hi Jared, On Mon, Jun 26, 2017 at 03:33:09PM -0500, Matt Weber wrote: From: Jared Bents Update to increase the pathname limit to the linux limit of 4096 characters. Similar patch: https://patchwork.openembedded.org/patch/131475/ Signed-off-by: Jared Bents Signed-off-by: Matt Weber --- miscutils/makedevs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/miscutils/makedevs.c b/miscutils/makedevs.c index 9e7ca34..0049edb 100644 --- a/miscutils/makedevs.c +++ b/miscutils/makedevs.c @@ -208,7 +208,7 @@ int makedevs_main(int argc UNUSED_PARAM, char **argv) unsigned count = 0; unsigned increment = 0; unsigned start = 0; - char name[41]; + char name[4096]; Why not use PATH_MAX here? Agree, that would be cleaner. Will submit v2 after some testing. That still leaves a hardcoded value in the sscanf of 4095 should I add a comment to the affect we're assuming PATH_MAX is at least 4096? Maybe a check is also needed? Alternatively you may use the m modifier, when implemented, to auto-allocate the name pointer. This way you don't have to hardcode anything in the sscanf(), you let the library for the job for you. Later, you can check the string length. Such a change would induce an allocation, a free but will also reduce stack usage. If we want to keep it all static, another option would be to stringify that define. (Courtesy Jared for this idea) + #define STRINGIFY(x) STRINGIFY2(x) + #define STRINGIFY2(x) #x . - if ((2 > sscanf(line, "%40s %c %o %40s %40s %u %u %u %u %u", + if ((2 > sscanf(line, "%" STRINGIFY(PATH_MAX) "s %c %o %40s %40s %u %u %u %u %u", If you ask for large enough allocations on the stack, GCC will secretly give you malloc/free instead, which adds to code size. It might be that 4096 triggers this effect, and perhaps that was the reason for the original small-ish static buffer. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: # CONFIG_BUSYBOX is not set: breakage on master
On 8/27/2016 2:18 AM, Cristian Ionescu-Idbohrn wrote: On Sat, 27 Aug 2016, Denys Vlasenko wrote: config BUSYBOX bool "Include busybox applet" default y help The busybox applet provides general help regarding busybox and allows the included applets to be listed. It's also required if applet links are to be installed at runtime. If you can live without these features disabling this will save some space. And this is also expected: $ ./busybox busybox: applet not found when executed immediately after build? And this too? $ ./busybox --help -help: applet not found $ ./busybox --list -list: applet not found Yes, adding or removing those behaviors is precisely the purpose of the CONFIG_BUSYBOX setting. Maybe you should explain your situation and what you expected? because a person reading your subject line would assume you are trying to say "I compiled busybox without the CONFIG_BUSYBOX flag, and now I'm surprised that it did what it said it would do"... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] getrandom: new applet
On 7/12/2016 5:53 PM, Rich Felker wrote: On Tue, Jul 12, 2016 at 01:09:42PM -0400, Michael Conrad wrote: On 7/7/2016 11:49 AM, Rob Landley wrote: On 07/06/2016 11:41 AM, Etienne Champetier wrote: Now you really hate the fact that getrandom() is a syscall. I do not hate the fact getrandom is a syscall. I'm asking what the point is of a new applet to call this syscall. You have suggested it could block to show when /dev/urandom is producing a higher grade of randomness than it does before being properly seeded. That is, as far as I can tell, the only reason for your new applet to exist rather than upgrading $RANDOM in ash/hush. Actually in my opinion the syscall is inferior to a new character device, because blocking syscalls interfere with event-driven programming. Suppose you want to write a single-thread event-driven web server which initializes its SSL library with this randomness source (i.e. won't allow SSL until enough entropy is collected for a good initialization) but you still want it to be able to accept non-SSL connections. In order to use the syscall you need a thread, or child process. (haha, such as pipe to a "getrandom" applet...) Thanks for contributing your ideas about what color the bikeshed should be, but getrandom's already got you covered. Until your csPRNG is initialized, just call getrandom with the GRND_NONBLOCK once each time you get any event (i.e. each time poll() returns). There's no need to busy-wait or periodically check with timeouts since you don't need the results until there's an event to act on, anyway. Not unless they add a feature to deliver a signal when it becomes un-blocked. And they don't have me covered unless the event library I'm using adds explicit support for it. If I'm using libevent or glib and was asked to write such a program today, I'd probably have to settle for polling with a timer, or a thread. There are very good reasons it's a syscall rather than a device: many use cases require a never-fails entropy source, and with the device node approach they're vulnerable to fd-exhaustion attacks. Most existing bad code, when faced with such a situation, falls back to some completely insecure seed like time(). The only reliable way to prevent such idiocy was to provide an interface that can't fail. It's trivial to open it at program start, and abort if you can't. If the FD is already open it will never fail. The "unix way" is to make things waitable via file handles, or via signals. I have a personal grudge against blocking system calls. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] getrandom: new applet
On 7/7/2016 11:49 AM, Rob Landley wrote: On 07/06/2016 11:41 AM, Etienne Champetier wrote: >Now you really hate the fact that getrandom() is a syscall. I do not hate the fact getrandom is a syscall. I'm asking what the point is of a new applet to call this syscall. You have suggested it could block to show when /dev/urandom is producing a higher grade of randomness than it does before being properly seeded. That is, as far as I can tell, the only reason for your new applet to exist rather than upgrading $RANDOM in ash/hush. Actually in my opinion the syscall is inferior to a new character device, because blocking syscalls interfere with event-driven programming. Suppose you want to write a single-thread event-driven web server which initializes its SSL library with this randomness source (i.e. won't allow SSL until enough entropy is collected for a good initialization) but you still want it to be able to accept non-SSL connections. In order to use the syscall you need a thread, or child process. (haha, such as pipe to a "getrandom" applet...) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox sed, 'r' command
On 3/23/2016 12:12 PM, Ralf Friedl wrote: Cristian Ionescu-Idbohrn wrote: sed (GNU sed) 4.2.2 can do this: $ printf 'foo bar baz' | sed r - foo bar baz or, after storing the text in a file: $ printf 'foo bar baz' >/tmp/bar $ sed r /tmp/bar foo bar baz But busybox sed can't: $ printf 'foo bar baz' | busybox sed r - sed: empty filename $ busybox sed r /tmp/bar sed: empty filename $ printf '' | busybox sed 'r /tmp/bar' $ busybox sed 'r /tmp/bar' The 'r' command is documented by GNU sed as a GNU extension. Still, busybox sed documents the 'r' command as supported: r [address]r file Read contents of file and append after the contents of the pattern space. Exactly one space must be put between r and the filename. Am I misinterpreting the documentation? From the documentation: > The full format for invoking `sed' is: > sed OPTIONS... [SCRIPT] [INPUTFILE...] So in your example you invoce sed with the script "r" and the input file "-" or "/tmp/bar". The content is not printed because it is the argument to the "r" command, but because it is the main input file to sed. You can avoid that by using quotes around the command and the file name, or by omitting the space between the command and the filename. You should also try the last two examples, where you invoke busybox sed with quotes, with GNU sed. The behaviour is the same. You should note that in your example when reading from a file, sed didn't read from stdin, at least you don't mention it, although your interpretation would mean that the filename is the argument to the "r" command, therefor no argument is given to sed, and sed should read stdin. You should also not that invoking the "r" command with the filename causes the content of this file to be inserted after every line. When reading from a pipe, the pipe is empty after the first line. My documentation to GNU sed 4.2.2 says: > `r FILENAME' > As a GNU extension, this command accepts two addresses. > > Queue the contents of FILENAME to be read and inserted into the > output stream at the end of the current cycle, or when the next > input line is read. Note that if FILENAME cannot be read, it is > treated as if it were an empty file, without any error indication. > > As a GNU `sed' extension, the special value `/dev/stdin' is > supported for the file name, which reads the contents of the > standard input. So the main difference seems to be that GNU sed doesn't give an error message if the file can't be read. I'm not sure why that would be a good idea. Also not that there is no mention of using "r -" for stdin, instead /dev/stdin is mentioned. On the other hand, I don't know why busybox sed needs exactly one space between command and filename. GNU sed works with zero or more spaces. It looks to me that what actually happens when running "sed r" is that it appends *no lines* to the end of each line read from stdin. $ printf 'foo bar baz' | sed Does not add a final newline $ printf 'foo bar baz' | sed r Does add a final newline $ printf 'foo bar baz' | sed 'r /dev/null' Does add a final newline echo "blah" > - $ printf 'foo bar baz' | sed 'r -' results in foo blah bar blah baz blah So it is not a special case for the filename. I personally don't see much value in preserving the behavior of appending nothing for a file which doesn't exist. Tools should give errors if they can't do what you ask them to. -Mike C. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v3 3/4] nsenter: new applet
On 3/16/2016 11:35 AM, Bartosz Gołaszewski wrote: 2016-03-15 21:45 GMT+01:00 Mike Frysinger : On 15 Mar 2016 12:00, Bartosz Gołaszewski wrote: Actually some time ago I sent a series extending the readahead applet. It was rejected eventually but one of the patches was actually adding a useful macro taken from systemd that seems to be doing a nice job at determining the right size for string buffers holding integers: http://lists.busybox.net/pipermail/busybox/2015-August/083302.html And Denys' reponse: 2015-08-25 14:52 GMT+02:00 Denys Vlasenko : I am using a mich simpler expression, sizeof(type)*3. type,sizeof(type)*3, actual reqd # of chars char 3 3 short6 5 int 12 10 int64_t 24 19 As you see, it is a quite good approximation. Let's see how it works in real-world example: char path[sizeof("/proc/self/fd/%d") + sizeof(int)*3]; char path[sizeof("/proc/self/fd/%d") + DECIMAL_STR_MAX(int)]; With current name, it becomes longer. Can you make this macro shorter? i think his example just goes to show that, even when you think about it, you get it wrong :). his examples miss the extra byte needed for the - sign, and he used %d which is signed (rather than %u which is unsigned). also, that macro is wrong for the same reason :). -mike What about #define INT_BUF_MAX(type) (sizeof(type) * 3 + 1)? It would give us (including the preceding '-' and terminating '\0'): sizeofbufsizeactual max 1 4 4 2 7 7 4 13 12 8 25 20 Or, use the actual 2.4 ratio, rounded up, plus sign, plus NUL. (and your "actual max" is wrong) #define INT_BUF_MAX(type) (sizeof(type) * 24 / 10 + 3) sizeofbufsizeactual max 1 5 5 2 7 7 4 12 12 8 22 21 The final one is only wrong because we added a byte for sign but a signed 64-bit is actually 63 bits which is a character shorter. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v3 3/4] nsenter: new applet
On 3/14/2016 2:27 PM, Mike Frysinger wrote: the code seems to assume that the byte size scales into the number of chars required to represent the number in base 10 when it's really a log scale. here's a table to show it's wonky: The number of bytes is also a log scale. The ratio of log_256 to log_10 is 2.4, so 3 is a reasonable approximation. It reasonably handles the case of 16-bit, 32-bit and 64-bit PIDs (which are all I would think would ever appear in the wild) I don't see what the complaint is since its only bytes of stack space anyway... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: NEED help with Busybox
These are mostly Unix questions, not busybox questions. But I'll answer off-list to get you started. On 3/6/2016 7:14 AM, Hiep Huynh wrote: Hi there, I'm a newbie to Busybox and I need your help with these questions: 1) How do I check if my Linux kernel system is using busybox? 2) Usually on a embedded Linux system, how does busybox get fired up after system boots? 3) When a command "top" is entered, could you help explain how that command is routed to use busybox's top? Or point me to any document? 4) Lastly, what are the steps to upgrade Busybox on existing Linux system? Thank you so much for your help. Hiep ___ 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] su: support denying accounts with blank password
On 10/14/2015 2:37 AM, Natanael Copa wrote: The security is based on physical access. The local technician can log in without password. (in theory, if you have physical access then you have access to it all anyway). And after all, it is the "local technician" the device is supposed to protect anyway. Why run 'login' at all? You can just run "agetty -l /bin/bash" from init or runit and always have a shell ready. Alternatively you can randomize the password and print it on the console with the welcome message. Just some other ideas. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How to use "read" in Busybox v1.1.1 ?
On 5/14/2015 12:38 PM, Mike Yates wrote: After all, I was only using "read" as a convenient "stop to debug" prompt. The ash "arg count" error prevented "read" from stopping the script and was almost disastrous! Ok, so by "works" you mean "stops to wait for a newline". That was the primary point of confusion. As I said, Busybox should either make its built-ins Posix Compliant or explain prominently why they are not (Almquist) or, better still, give a "usage" line on failure. http://pubs.opengroup.org/onlinepubs/9699919799//utilities/read.html This document says nothing about the variable being optional or any reference to the $REPLY variable. Do you have a link to a document that says otherwise? I'm sure you will sggest a more reliable method? If you want the widest compatibility with shells, simply say "read REPLY", and/or actually require the value you read to be "yes" or "y" before continuing, which is what most people do. Also, I like to use "set -e" so that any command which fails will exit the shell. The shell's default of continuing after failed commands is the dangerous part. That said, it doesn't seem like a bad idea to add $REPLY support to busybox sh if it can be written in a few bytes, which I suspect it can. -Mike C ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How to use "read" in Busybox v1.1.1 ?
On 5/14/2015 11:33 AM, Mike Yates wrote: On 13 May 2015 at 16:27, Michael Conrad wrote: On 5/13/2015 7:45 AM, Mike Yates wrote: read -p "Enter name: " $name I have found that the "$" is the issue - Busybox will only accept a variable name without it, while Bash accepts either, or the null variable. I think you have some other error in your script giving this illusion. No, I do not - the command line I gave is now working just fine, without the "$". I have tested everything at the command-line anyway. I had been trying a null or existing (but unassigned) variable, as used in Bash, while Busybox v1.1.1 only accepts new or assigned variables. You are using some strange terminology here. What is a null variable? an "existing but unassigned" variable? AFAIK the shell doesn't have these concepts. If the variable exists it must have a value, though it could be an empty string. I mean "read", "read $v" and "read v" all work in Bash, but only "read v" in Ash (Busybox). By your own examples below, "read $v" does *not* work in bash. Unless your definition of "work" is "doesn't throw an error" but it clearly doesn't store the value in $v. -Mike C. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How to use "read" in Busybox v1.1.1 ?
On 5/13/2015 11:30 AM, Jody Bruchon wrote: On 05/13/2015 11:27 AM, Michael Conrad wrote: My bash behaves like busybox. As far as I know it has never been possible to "read $foo" and get the value placed into $foo (unless $foo=foo) I confirmed that bash on one of my servers does allow use of 'read $foo' instead of 'read foo'. It seems like a bad idea though; if a POSIX sh-compatible script sets foo=bar and goes 'read $foo' to effectively perform a 'read bar' then bash will break it. The oldest bash I have is GNU bash, version 4.2.53(1)-release (i386-pc-linux-gnu) Copyright (C) 2011 Free Software Foundation, Inc. and doesn't work there either. I'm curious, what happens in your version of bash if you use read in a loop? while read $foo; do echo $foo; done Does it start writing to an unintended variable on the second iteration? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How to use "read" in Busybox v1.1.1 ?
On 5/13/2015 7:45 AM, Mike Yates wrote: On 11 May 2015 at 20:01, Bastian Bittorf wrote: * Mike Yates [11.05.2015 18:05]: The command "read" in Busybox v1.23 functions just like in GNU bash but in the v1.1.1 in my old NAS it keeps complaining of not enough arguments. what is your exact commandline? read -p "Enter name: " $name I have found that the "$" is the issue - Busybox will only accept a variable name without it, while Bash accepts either, or the null variable. I think you have some other error in your script giving this illusion. My bash behaves like busybox. As far as I know it has never been possible to "read $foo" and get the value placed into $foo (unless $foo=foo) $ bash --version GNU bash, version 4.3.33(1)-release (x86_64-unknown-linux-gnu) ... $ x=a $ read $x blahblah $ echo $x a $ echo $a blahblah ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Add a user/password interface for a Telnet and ftp connect
On 03/18/2015 10:50 AM, Alexis Guilloteau wrote: Hi, Right now i can run a Telnet daemon on one of my board using the command "/usb/sbin/telnet -l /bin/sh" and run a ftp daemon thanks to inetd.conf but each of the connection are anonymous (well, it ask for a user name but not for a password...) After looking at the help of the ftpd function in busybox i know that the main function is to create an anonymous ftp server so i was not surprised with the lack but do you think there would be a solution for that ? I would think it would be to work into the .c file of the function but maybe you have another idea. And pretty much the same thing for telnetd. Right now the only user on the board is the root with no password. If you do want any sort of security, you are better off using ssh and sftp. Telnet and ftp don't really offer any security even with passwords, so there is little interest in adding support for permissions to those applets. The most popular ssh for embedded is 'dropbear': https://matt.ucc.asn.au/dropbear/dropbear.html -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] Proof-of-concept for netlink listener for mdev -i
On 03/15/2015 12:16 PM, Laurent Bercot wrote: On 15/03/2015 15:52, Natanael Copa wrote: I have simplified the long-time living netlink listener more by forwarding the netlink socket and letting the handler read directly from netlink. This factorize out the pipe and remove the need of any micro protocol. As I wrote in another message, there is basically no benefit in doing that, because it forces the handler to be netlink-aware. But then it would still need to be micro-protocol-aware. The netlink protocol is nearly identical to the micro-protocol you proposed earlier; maybe being netlink-aware isn't so bad? The main difference is whether it uses recv() expecting a datagram or read() and has to parse some message framing. I'd bet the first requires less code. And, it doesn't have to be a netlink socket; the messages could be relayed through any datagram socket. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 3/13/2015 11:21 AM, Harald Becker wrote: On 13.03.2015 12:41, Michael Conrad wrote: Stream-writes are not atomic, and your message can theoretically get cut in half and interleaved with another process writing the same fifo. (in practice, this is unlikely, but still an invalid design) ---snip--- O_NONBLOCK disabled, n <= PIPE_BUF All n bytes are written atomically; write(2) may block if there is not room for n bytes to be written immediately ---snip--- I stand corrected. I thought there would be a partial write if the pipe was mostly full, but indeed, it blocks. If someone really wants a netlink solution they will not be happy with a fifo approximation of one. You missed the fact, my approach allows for free selection of the mechanism. C hosing netlink means using netlink, as it should be. The event listener part is as small as possible and write to the pipe, which fire up a parser / handler to consume the event messages. Are you suggesting even the netlink mode will have a process reading the netlink socket and writing the fifo, so another process and can process the fifo? The netlink messages are already a simple protocol, just use it as-is. Pass the On 3/13/2015 12:14 PM, Harald Becker wrote: The new code would not be run like a hotplug helper, it would be run as a daemon, probably from a supervisor. But the old code is still there and can still be run as a hotplug helper. The new code behaves exactly as the old code. When used as a hotplug helper, it suffers from parsing conf for each event. My approach is a splitting of the old mdev into two active threads, which avoid those problems even for those who like to stay at kernel hotplug. Then it sounds like indeed, you are introducing new configuration steps for the old-style hotplug helper? i.e. where does the fifo live? who owns it? what security implications does this have? Who starts the single back-end mdev processor? If started from the hotplug-helper, who ensures that only one gets started? If people have existing systems using hotplug-helper mdev, you can't just change the implementation on them in a way that requires extra configuration. Everyone who has commented on this thread so far agrees with that. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 3/13/2015 9:48 AM, Harald Becker wrote: On 13.03.2015 12:29, Michael Conrad wrote: On 3/13/2015 3:25 AM, Harald Becker wrote: 1 - kernel-spawned hotplug helpers is the traditional way, 2 - netlink socket daemon is the "right way to solve the forkbomb problem" ACK, but #2 blocks usage for those who like / need to stay at #1 / #0 In that case, I would offer this idea: All you do, is throwing in complex code sharing and the need to chose a mechanism ahead at build time, to allow for switching to some newer stuff ... but what about pre-generated binary versions, which mechanism shall be used in the default options, which mechanism shall be offered? Please review it again. My solution solves both #1 and #2 in the same binary, with no code duplication. At first complex code reusage, and then: How will you do it without suffering from hotplug handler problem as current mdev? I'm don't seeing, that you try to handle this problem. My solution is to enable kernel hotplug handler mechanism to also benefit and avoid that parallel parsing for each event. ... beside that, this close / open_netlink look suspicious, looks like possible race condition. I thought pseudocode would be clearer than English text, but I suppose my pseudocode is still really just English... Maybe some comments will help. The new code would not be run like a hotplug helper, it would be run as a daemon, probably from a supervisor. But the old code is still there and can still be run as a hotplug helper. mdev_main() { read_options(); load_config(); // if user requests "--netlink" mode, we act like a daemon if (option_netlink) { // If "--netlink-on-stdin" then netlink is open for us already // if not, then we need to create our netlink socket if (!option_netlink_on_stdin) { close(0); // the new socket will now be file descriptor 0 open_netlink_socket(); } // use 'select()' to see if a new netlink message is ready. // if the user gave us a "--timeout" then we exit if no new // netlink message in a certain amount of time while (select([0], timeout)) { if (recv(0, message)) { // Netlink message is a list of variables. We call 'setenv' for each. apply_env_from_message(message); // Now we have all the hotplug variables. So call the old code. process_request(); } // keep running in a loop until timeout (or forever if no timeout) } } else #endif process_request(); } ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 3/13/2015 3:25 AM, Harald Becker wrote: This is splitting operation of a big process in different threads, using an interprocess communication method. Using a named pipe (fifo) is the proven Unix way for this ... and it allows #2 without blocking #1 or #0. Multiple processes writing into the same fifo is not a valid design. Stream-writes are not atomic, and your message can theoretically get cut in half and interleaved with another process writing the same fifo. (in practice, this is unlikely, but still an invalid design) If you want to do this you need a unix datagram socket, like they use for syslog. It is also a broken approximation of netlink because you don't preserve the ordering that netlink would give you, which according to the kernel documentation was one of the driving factors to invent it. If someone really wants a netlink solution they will not be happy with a fifo approximation of one. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 3/13/2015 3:25 AM, Harald Becker wrote: 1 - kernel-spawned hotplug helpers is the traditional way, 2 - netlink socket daemon is the "right way to solve the forkbomb problem" ACK, but #2 blocks usage for those who like / need to stay at #1 / #0 In that case, I would offer this idea: All you do, is throwing in complex code sharing and the need to chose a mechanism ahead at build time, to allow for switching to some newer stuff ... but what about pre-generated binary versions, which mechanism shall be used in the default options, which mechanism shall be offered? Please review it again. My solution solves both #1 and #2 in the same binary, with no code duplication. I suggested wrapping #2 in a ifdef for the people who don't have netlink at all, such as on BSD, and also anyone who doesn't want the extra bytes. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 03/12/2015 04:32 PM, Harald Becker wrote: On 12.03.2015 19:38, Michael Conrad wrote: On 3/12/2015 12:04 PM, Harald Becker wrote: but that one will only work when you either use the kernel hotplug helper mechanism, or the netlink approach. You drop out those who can't / doesn't want to use either. ...which I really do think could be answered in one paragraph :-) If the netlink socket is the "right way" to solve the forkbomb problem that happens with hotplug helpers, then why would anyone want to solve it the wrong way? I don't understand the need. To clarify, 1 - kernel-spawned hotplug helpers is the traditional way, 2 - netlink socket daemon is the "right way to solve the forkbomb problem" 3 - kernel-spawned fifo-writer, with fifo read by hotplug daemon is "solve it the wrong way". ohh, good question! ... ask Isaac! (answer in one paragraph?) What I hear Isaac say is "leave #1 (traditional way) alone. I want to keep using it". I agree with him that it should stay. But I would choose to use #2 if it were available. I am asking the purpose of #3. Conclusion: As I accept different preferences, and I do not want to force others more than possible, I tried to find a solution which allows every required mechanism (with maximum code sharing), and let the user chose which one to use. In addition BB has a config system which allows to disable unwanted stuff, so you can opt out the hotplug stuff when you like. So I think your answer to my original question is "the fifo design is a way to have #1 and #2 without duplicating code". In that case, I would offer this idea: 1. Refactor mdev to look like this: (pseudocode) mdev_main() { read_options(); load_config(); process_request(); // from environment variables } 2. Add the following: mdev_main() { read_options(); load_config(); #ifdef FEATURE_MDEV_NETLINK if (option_netlink) { open_netlink_socket(); while (recv(message)) { apply_env_from_message(message); process_request(); } } else #endif process_request(); } 3. Then to support the ability to launch mdev connected to a netlink socket that already exists, and time out when not used, mdev_main() { read_options(); load_config(); #ifdef FEATURE_MDEV_NETLINK if (option_netlink) { if (!option_netlink_on_stdin) { close(0); open_netlink_socket(); } while (select([0], timeout)) { if (recv(0, message)) { apply_env_from_message(message); process_request(); } } } else #endif process_request(); } I think this will be even smaller than what you propose with the fifo. It will do netlink, it will do the traditional hotplug helper, and even allow the trick where a tiny daemon monitors netlink and can start mdev in daemon mode on demand. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
The question I was asking was only about this: On 3/12/2015 12:04 PM, Harald Becker wrote: but that one will only work when you either use the kernel hotplug helper mechanism, or the netlink approach. You drop out those who can't / doesn't want to use either. ...which I really do think could be answered in one paragraph :-) If the netlink socket is the "right way" to solve the forkbomb problem that happens with hotplug helpers, then why would anyone want to solve it the wrong way? I don't understand the need. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 3/11/2015 9:30 AM, Harald Becker wrote: So how can we avoid that unwanted parallelism, but still enable all of the above usage scenarios *and* still have a maximum of code sharing *and* a minimum of memory usage *without* delaying the average event handling too much? The gathering parts need to acquire the device information, sanitize this information, and serialize the event operations to the right order. The device node handling part shall receive the information from the gathering part(s) (whichever is used) and call the required operations, but shall avoid reparsing the conf on every event (speed up) *and* drop as much memory usage as possible, when the event system is idle. My idea is a fifo approach. This allows splitting the device management functionalities. Nevertheless which approach to gather the device information is used, the parser and device handling part can be shared (even on a mixed usage scenario). Supposing that we have * mdev acting as a parallel hotplug handler forked by the kernel and then add * mdevd which reads netlink messages and runs as a daemon What specifically is the appeal of a third approach which tries to re-create the kernel netlink design in user-land using a fifo written from forked hotplug helpers? I'm interested in this thread, but there is too much to read. Can you explain your reason in one concise paragraph? -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question on busybox and loading firmware?
On 9/23/2014 2:05 AM, Michael D. Setzer II wrote: device class 'firmware': registering pci :02:08.0: Firmware left e100 interrupts enabled; disabling ipw2200 :02:02.0: Direct firmware load failed with error -2 firmware ipw2200-bss.fw: firmware: requesting ipw2200-bss.fw ipw2200: ipw2200-bss.fw request_firmware failed: Reason -12 ipw2200: Unable to load firmware: -12 usbserial: USB Serial support registered for Keyspan - (without firmware) psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 Most google results show -2. Maybe check the kernel source to see what -12 is? ...takes about 1:46 to get to the loading of the file system, so not sure where the 60 seconds timeout starts, or if that is what is making it take so long?? On desktop system, the kernel loads in about 15 seconds. If you enable timestamps in the kernel logging it can help find things that are taking a long time to initialize. 1:46 seems a bit excessive. If this does end up being the problem that the kernel firmware loader times out before the root filesystem even gets loaded, you might be able to edit the timeout in the kernel source. Another message talked about a hot plugin script, but there are two variables that it says are defined in the envirnonment, and I can not find them? Also, not sure if it would apply, since I thought hotplug was for devices that are later plugged into the system instead of devices that are actually built into the sytem. These environment variables exist only when when the kernel is asking for firmware. The hotplug interface is used for pretty much all communication from the kernel to userspace about driver-things. A quick way to debug is with a script like #! /bin/sh echo "---" >> /var/log/hotplug_requests.log /usr/bin/env >> /var/log/hotplug_requests.log exec /sbin/mdev HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/ firmware is typically located at /lib/firmware. This is where mdev would look for it by default. Did a search in the /sys directory to look for any file called loading, but none exist on notebook or desktop systems I've seen. They are created on demand by the kernel, matching the environment variables given to hotplug. Thanks again. If I had more time available I could give better examples, but there are past examples in the archives of this list. Good luck! -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question on busybox and loading firmware?
On 9/22/2014 10:27 AM, Michael D. Setzer II wrote: On 22 Sep 2014 at 10:32, Gustavo Zacarias wrote: On 09/22/2014 09:56 AM, Michael D. Setzer II wrote: Was already able to find the firmware since it was included with the installation of the fedora 20 on the notebook. Issue is that I placed the firmware files into the /lib/firmware directory, but on booting from my project kernel it seems to try and load firmware during the kernel loading before the ramdisk.lzma is loaded. The kernel is built with the option to not include firmware, since I don't know what if any firmware will be needed by end users. This seems to have worked with bnx2 and bnx2x firmware that another end user needed. But the booting showed the messages before the ramdisk.lzma is recognized, and then shows messages with =-12, and =-2. Didn't save the output since this was a ram only load. Was thinking that mdev -s might cause it to load firmware. Kernel contains most disk and ethernet devices included. Hi. Make the driver a module instead of built into the kernel. The driver might initialize before the kernel/userland has access/mounted a root filesystem and that's what happens. Thanks for the reply. Problem is that iso has the option of select 7 different kernels, so if I changed it to using moduals I would have to include them for multiple kernels and also come up with a script to load the moduals. Right now everything works by having the kernels handle the hardware. I think the "right way" to handle that is to have each kernel look for a different /lib/modules/* directory. You shouldn't need a special script to load modules because the kernel should report them to mdev and it should "just work". But I understand wanting to have a static kernel for simplicity. Anyway, when the kernel tries to load firmware, you should get a 60-second timeout before it gives up. If you have more than 60 seconds between when the module gets initialized and when your filesystem gets mounted, then that could be the problem. There are past messages on this list that show how to get better logging of what the kernel is asking from mdev, which might help you find the problem. What I have done for my static kernels is to include the firmware into the compiled kernel. This is best when you know that the kernel will always need the firmware. (but if you are doing this for lots optional hardware, you can end up with a very large kernel, which is worse than needing to load firmware from the filesystem) Don't remember offhand, but there is a kernel config where you tell it the directory of the firmware, and tell it what filenames to include, and then those files get sucked in when you compile the kernel and are automatically available at boot. Hope that helps, -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How do I (unconditionally) enable unicode support in busybox?
On 08/10/2014 03:39 AM, James Bowlin wrote: I ran into problems like this years ago when I tried it before. I had given up before because there were just so many variables (kernel header version ublibc version, binutils version, buildroot version, busybox version, and more) that could cause the segfault. I think patches may be needed too. My guess is that it will work with uclibc but is flakey with glibc. Want a cheap trick for getting it all to work? Extract gentoo-uclibc in a directory, chroot into it (with a number of the Gentoo install steps like setting up resolv.conf and /dev and /proc) and then "USE=static emerge busybox". Gentoo-uclibc in a chroot is my weapon of choice these days. I hate cross-compiling with a passion. (would love to see someone put together a gentoo-musl! ) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: shutdown busybox and start another PID1 process
On 08/09/2014 07:02 AM, Rieker Flaik wrote: But here I can't do that because /sbin/init has taken over PID 1 and spawned processes. So I first have to shut this "pre-OS" down before booting into the next. Is there a way to kill all processes and start a shellscript as PID 1 again? Maybe by tweaking /etc/inittab and its restart option? Or do I need to hack the source in busybox-1.22.0/init/init.c? As tito said, kexec is probably the best option. But I would add that runsvdir (runit suite, also part of busybox) would probably serve your needs better than init. Run a shell script as PID 1, have it run runsvdir, and then when your backup script is complete just kill the runsvdir and it will cleanly shut down all the services, and return. Then the PID 1 script can exec things like normal. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How do I (unconditionally) enable unicode support in busybox?
On 8/4/2014 2:48 PM, James Bowlin wrote: BTW, the following code is an infinite loop in my initrd: [ "$LANG" = "en_US.UTF-8" ] || LANG=en_US.UTF-8 exec "$0" "$@" I think you should focus on this bug. Which busybox version? Which libc version? Because my busybox runs it just fine. (as should any conforming shell) ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] top: fix parsing of /proc/meminfo
On 07/21/2014 04:44 PM, Dan Fandrich wrote: On Sun, Jul 20, 2014 at 11:20:13AM +0300, Timo Teras wrote: On Sat, 19 Jul 2014 21:31:33 +0200 Dan Fandrich wrote: On Fri, Jul 18, 2014 at 10:07:06PM +0300, Timo Teräs wrote: and do it in smaller code: diff --git a/procps/top.c b/procps/top.c index 530f45f..e60dab6 100644 --- a/procps/top.c +++ b/procps/top.c @@ -501,10 +501,27 @@ static void display_cpus(int scr_width, char *scrbuf, int *lines_rem_p) static unsigned long display_header(int scr_width, int *lines_rem_p) { + static const char *fields = Minor suggestion: this should be static const char * const fields = so it can go into .rodata. That said, adding the second "const" does make sense. And thinking more, "static" should probably be left out. static needs to be left in in order to avoid a copy of the structure onto the stack at run-time. All this may be moot with an optimizing compiler, but not all compilers are necessarily smart enough to do this on their own. Adding those keywords also makes it more clear what the intent is of the structure. Am I missing something here? There is no structure, just a character pointer. If you leave off "static" it will be compiled as an instruction that pushes a constant onto the stack, by any/every compiler. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: /proc//cmdline and udhcpcd
On 03/26/2014 09:13 AM, Cristian Ionescu-Idbohrn wrote: On Wed, 26 Mar 2014, Denys Vlasenko wrote: But how that respawn tool going to work with other programs? As I've written in a previous message, I know nothing of such other programs, but I'd be intrested to learn more. There is no convention in Unix that you can't modify argv[]. Sad, because if there was, there would have been something to refer to. daemontools and runit's runsvdir both have a feature where they log to the cmdline, as a ... clever? way of not relying on a writable logging destination. http://smarden.org/runit/runsvdir.8.html I'm aware of quite a few Perl daemons that overwrite their proc title (otherwise you'd end up with "perl ..." all over your ps listing). Examples include Catalyst and Plack fast-cgi servers. I've personally written C code that replaces the "=" with "\0" in options like "--option-foo=VALUE". Not in any published open-source though, I don't think... All mysql utilities overwrite passwords in cmdline as a security measure. http://dev.mysql.com/doc/refman/5.1/en/password-security-user.html So in short, its a thing that the Linux world has been doing for a long time, though infrequently. I'm sure someone at your work thought re-using /proc/*/cmdline was a really cool idea, and built a system around it, and this system might have been working ok for you so far. And I sympathize with this situation. However, there exists a holy-grail design of process management that is frequently advertised on this list, where you have one runscript per persistent daemon, and a daemon manager which runs all the daemons as child processes, and restarts them if they exit unexpectedly. And this design is probably actually what you want. So if you're interested in learning something new and highly effective for process management, check out the tools "runit", "s6", "perp" (or, my own recently completed 'daemonproxy'). Also, runit is available as a busybox applet. http://smarden.org/runit/ http://skarnet.org/software/s6/why.html http://b0llix.net/perp/ https://github.com/silverdirk/daemonproxy While a paradigm-shift could be painful, a quick fix could be as simple as having your current process monitor watch an instance of runsv instead of udhcpcd, and in turn, runsv would monitor udhcpcd. Hope that helps. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
On 3/18/2014 3:54 PM, Mike Dean wrote: So you're telling me that a plain text script which takes more than 300 bytes is a better solution than an option that could be configured out? But your full text option, enabled by default, takes less than 300 bytes I suppose? I'm not sure I follow. Harald suggested adding 23 bytes to your existing script, and adds the convenience of a config file where there wasn't before. You could add that same minimal config file in C, and it would take a lot more than 23 bytes. Either way, the "config file" will be a thing specific to busybox ntpd and you will have the exact same documentation problem in teaching people how to use it, then they have learning about the "-p" command line switch. If you want to be compatible with a standard tool, and support "ntp.conf", then you gain the popularly-available documentation, but add a significant amount of code. Neither way is really ideal. So if you want to add a non-ideal solution, it should be done in a distro-specific script. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ntpd config file support
On 3/18/2014 3:09 PM, Mike Dean wrote: Helping them with this usually results in grumbling about it being overcomplicated to perform what should be such a simple task. IMHO, the plethora of unix config file syntaxes are much harder to learn than reading a quick manpage (or --help in this case) of the tool you want to run. Where are they going to learn the syntax? Your documentation? Random Internet documentation for the real ntpd? The man page for the real ntp.conf is 1700 lines long! On 3/18/2014 3:09 PM, Mike Dean wrote: I personally don't see how this tiny addition represents any significant increase to the size of the source tree or the compiled binary. What syntax should be used? the full ntpd syntax? Should busybox emit errors or warnings on directives it doesn't support? I can't imagine you could add this feature properly in less than 300 bytes, and that is significant for busybox. On 3/18/2014 2:31 PM, Harald Becker wrote: ntpd -p `cat /etc/timeserver` I'm inclined to side with Harald that this is the best solution. Can't be much simpler for the user than that... -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Running a script every second
I know this borders on bike-shedding, but if you really want to run something exactly 60 times per elapsed minute you need to compare calls to clock_gettime(CLOCK_MONOTONIC). Nothing else will work reliably in all cases, and certainly not signals. (if the system is lagged significantly, two signals can be merged into one) I'm not aware of any way to call clock_gettime from a shell script, but Perl can do it. If you don't have perl and you still want it to be a script for ease-of-maintenance, I would recommend: 1. write a very small C program that calls clock_gettime() for an initial timestamp, writes "\n" on STDOUT, increment timestamp by exactly 1 second, calls clock_gettime(), and then usleep()s for the difference between clock_gettime and timestamp, if greater than 0. 2. write a script that performs "./c_prog | while read; do something(); done" No special file descriptors, process IDs, signals or other mess, and guaranteed one iteration of the script per every elapsed second (but no guarantee that the execution occurs during that second. Linux isn't realtime, afterall) -Mike On 3/6/2014 9:25 AM, Yan Seiner wrote: On 03/05/2014 10:49 PM, Harald Becker wrote: Hi Yan ! On 05-03-2014 09:14 Yan Seiner wrote: I am trying to run a script every second. Beside what Laurent told about using sleep, etc. first script (the one that does the work) trap 'update' HUP mknod /tmp/dummyfifo p while true; do read < /tmp/dummyfifo > /dev/null 2>&1 done The problem is that the 'read' generates a /usr/bin/update: line 1: can't open /tmp/dummyfifo: Interrupted system call The reason for this is you create your pipe once, but open it again at every iteration of the loop. Try the following: mknod /tmp/dummyfifo p exec 0/dev/null 2>&1 while true; do read done This opens the fifo once and assigns it for stdin. After that it stays open until the first script is terminated in any way. In addition stdout *AND* stderr are redirected to /dev/null for all following commands in the script, so you need to redirect to any file or tty when you want do display something. Thanks! I like it. My solution leaves 'cat' processes behind if the script gets killed. Usually not a problem since it's only invoked at boot. ___ 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: Looking for simple ifplugd example script
On 02/21/2014 05:39 AM, Bryan Evenson wrote: It means that busybox/examples/var_service/README is badly located, or badly written, or both. I found the README you were talking about. I have never used runsvdir before and I don't have it included in my version of Busybox. I didn't realize that Busybox was assuming you'd use runsvdir to run ifplugd, which was the start of my confusion. And since I didn't know that's what was assumed, I didn't think to look a couple directories up for a related README. A little more background on my system. It's an ARM family processor and I'm using the Yocto Project's Poky distribution on my system. The default image for that build uses sysVinit and is setup for ifup/ifdown. Every distro has a different take on how networking should be handled. It isn't practical for busybox to have networking configuration examples for every distro. If you want to make use of ifplugd, you first need to understand the design and layout of your distro. The example configs are only meant to help you understand how the tool works. That said, Denys was asking what could be done to the docs to help you on this path. So if I wanted to use ifplugd, is the suggestion that I include runsvdir and runsv in my Busybox configuration and use it to run ifplugd? I'm unclear what runsvdir is doing that sysVinit can't. If you want sane networking in a non-trivial situation, I think ifup isn't the tool. If not ifup, what would you suggest? I'm open to ideas, just looking for the simplest path to get to where I want to go. While busybox clones many classic tools, there is a sentiment among many developers and users that some of these classic tools suffer from design flaws and shouldn't be used. IMHO your best bet for a quick solution is to stick with your distro's way of doing things. But if you have the time for the learning curve, the best way to get rock-solid reliability from your system is to toss anything having to do with ifup/ifdown or sysvinit or init scripts, learn the actual commands and daemons needed for your system to function, and put these bare essentials into runit-style scripts. But this is an opinion. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ping: try SOCK_DGRAM if no root privileges
On 1/10/2014 12:37 AM, Laurent Bercot wrote: You're performing too much work copying your argument list. :P The wrapper should be entirely transparent: busybox shouldn't even notice it has been run through it, so it should be called with the exact same argv. Here's what I do [...] If you didn't want to have to maintain the list within the binary, and want to depend on the filesystem to declare which applets are allowed, you could write the wrapper to stat "/bin/$NAME" to verify that it (and "/" and "/bin") are * owned by root * not writable by other users * on the root filesystem (compare device number to device number of "/") * has set-uid bit This would be authorization-by-the-filesystem that you could rely on, and is intuitive to configure. It's a lot more code to write, but would still be a small binary. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: bnx2 firmware loading?
On 12/03/2013 09:15 AM, Lauri Kasanen wrote: Recent kernels can load firmware without userspace help, perhaps you'd want to backport those changes. Interesting! However I like the ability to log which firmware blobs were attempted. Maybe the right fix is a kernel build option to always log firmware load attempts. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: bnx2 firmware loading?
On 12/2/2013 4:58 PM, Michael Di Domenico wrote: when i try to do a 'modprobe bnx2', it fails with a message saying it cannot load the firmware files 'bnx2/bnx-firmware-0.6.1b.fw' however, i do in fact have the firmware files in '/lib/firmware/bnx2' oddly enough the bnx2 module does load after the 'unable to load firmware' error messages spit out, but no ethernet devices show up i'm *sure* i'm doing something wrong, but googling around hasn't shed any answers any thoughts or directions? I use the following script to help debug these sorts of things. - /sbin/hotplug - #! /bin/sh if test -n "$MODALIAS" -o -n "$FIRMWARE"; then echo hotplug: `env | sort` > /dev/kmsg; fi test -n "$MODALIAS" && modprobe "$MODALIAS"; exec /bin/mdev "$@"; - It prints to the kernel log, so you can find the output with dmesg or the serial console or whatever is convenient. Hope that helps. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question about the installation directory of programs
On 11/8/2013 9:57 PM, ChenQi wrote: I'm asking this because our project may also need a separation of / and /usr. In other words, we need to make sure the system can still boot up for recovery and repair even if /usr is missing. As busybox is an important part of our system, I want to know your opinions on this issue. IMHO, try this: Install busybox at /bin and /sbin, and install all applets (either symlinks or hardlinks) in those dirs. Create /usr mountpoint. Make /usr/bin symlink to ../bin Make /usr/sbin symlink to ../sbin In your "usr" partition which gets mounted at /usr, make symlinks for each busybox applet to ../../[s]bin/$APPLET Now, before you mount /usr, you still can access any busybox /usr/bin/$APPLET, and when you mount the real /usr, it will hide the directory symlinks, but the symlinks to each applet will take their place, and you still have access to them. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] init: handle kexec clean reboot
On 05/22/2013 10:28 PM, Harald Becker wrote: To grab Laurent's idea: What about a separate shutdown applet in Busybox: kill(-1,TERM), sleep, kill(-1,KILL), sleep, umount, sync then exec into the given remainder of command line? And remove all special shutdown processing from init process? Vor easy shutdown we can do: shutdown poweroff -f ... or: shutdown kexec whatever Since the topic interests people, I figured I'd share a utility I wrote recently. It's designed to be the program that init execs into, and it runs a shutdown script with a N second timeout. https://github.com/silverdirk/failsafe_shutdown Its purpose is to make sure that the system goes down, and doesn't get hung permanently due to unexpected situations. If the child script doesn't complete, or exits with an unexpected value, it does the usual "kill, remount-ro, sync, reboot". As a convenience, it allows the script return value to determine which reboot action is called. (though the script can perform its own reboot call) Also, does anyone happen to know if there is a way to activate the sysrq_trigger actions through a syscall, without needing /proc mounted? -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] init: handle kexec clean reboot
On 05/22/2013 01:41 PM, Laurent Bercot wrote: So, as I expected, killall5 is a heavy monster, scanning the process list in /proc (so, not portable), and killing them one by one unless they match some criteria. Absolutely ugly, needs some specific tweaks to support FUSE, and would exhibit a huge race condition if it didn't SIGSTOP all processes before scanning and SIGCONT them after killing. Isn't that because killall kills by name? It would have to scan the process list, then. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On 03/30/2013 01:58 PM, Ralf Friedl wrote: The kernel is never compiled with an initramfs. The kernel is often compiled to use an initramfs, if the boot loader supplies one. Actually, check kconfig for newer kernels. They have an option to automatically create the cpio archive from a directory of your choice and build it directly into the kernel image. I used this for a while because it seemed convenient, but then decided I'd rather decouple the kernel from the initrd so I could mix & match (and do things like init=/bin/sh). I imagine it makes life easier for people with limited bootloaders, or people making advanced use of kexec. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On 03/30/2013 05:34 AM, Laurent Bercot wrote: So perhaps the confusion is that Linux is simply not delivering the signal (regardless of sigprocmask) unless you install a signal handler. No, this is not the problem. Every shell in the world traps SIGINT. Hm, true... but then the problem you actually have is that there might be signals that the shell is allowing to be delivered that you didn't expect. I question whether anyone would actually want to write a shell script with signal handling to act as "init"... that seems messy and error prone. Lots of people do that, and for good reasons: see http://skarnet.org/software/s6/s6-svscan-1.html You make great arguments for stage 1 and 3, but it still seems a shell is ill-suited for stage 2. You would have to handle any signal where you didn't want the shell's default behavior, and if I remember right, there was also a trick needed to get the shell to reap zombies. It just seems too easy to write a tiny C program that 1 - launches a supervisor 2 - reaps zombies 3 - runs a script when it receives signals 4 - execs stage 3 when the supervisor exits Not to mention the large number of supervisor programs that already do this. I use shells as init sometimes, but mostly just for diagnostics. I'm not even sure if there is a command-line access to this call. echo 0 > /proc/sys/kernel/ctrl-alt-del Ah, nice. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: CTRL-ALT-DEL not working as expected. Seeking for advices
On 03/29/2013 11:56 AM, Harald Becker wrote: Hi Denys ! Hence my suggestion to add this sigprocmask to unblock all signals *AND* restore all signal actions to there default as part of the cttyhack applet. I would like to hear people confirming that kernel indeed blocks ant signals to pid 1. Which kernel version does that? Linux 3.0.0 and 3.6.11 do not mask any signals. And it's easy to find out! /root # gcc init-debug.c (see attached init-debug.c) followed by editing grub's boot line during a reboot: kernel (hd0,0)/vmlinuz-... root=/dev/sda2 init=/root/a.out revealing SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: CapEff: CapBnd: Meanwhile, the man page for kill (2) says: The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally. So perhaps the confusion is that Linux is simply not delivering the signal (regardless of sigprocmask) unless you install a signal handler. I question whether anyone would actually want to write a shell script with signal handling to act as "init"... that seems messy and error prone. Anyway, this little test also reveals that (as I thought I remembered) you have to make a special syscall to get the ctrl-alt-del behavior. Namely, reboot(RB_DISABLE_CAD); causes the system to stop instantly rebooting when ctrl-alt-del is pressed, and instead send SIGINT to pid 1. I'm not even sure if there is a command-line access to this call. I've only ever done it from C. setting on entrance. So the central place to trow that signal unblocking/default action restoring is the place used to startup the shell, usually the cttyhack applet. - Restoring signal actions to there default and unblocking doesn't harm if it's done without being required. It just waste some time/code space, but avoids lengthy debug sessions due to blocked signal handling. Can you name any actual cases where busybox caused signals to be blocked? Again, I'm suspecting that the real problem all along was either a missing call to reboot (2) or not installing a handler and causing the kernel to not deliver the signal. -Mike #include #include #include #include #include void sig_handler(int sig_num) { fprintf(stderr, "Caught signal %d\n", sig_num); } int main() { char buf[4096]; int fd, got, i; struct sigaction sa; if (mount("proc", "/proc", "proc", 0, "") != 0) perror("mount(proc)"); if ((fd= open("/proc/1/status", O_RDONLY)) < 0) perror("read(/proc/1/status)"); got= read(fd, buf, sizeof(buf)); sleep(5); write(1, buf, got); memset(&sa, 0, sizeof(sa)); sa.sa_handler= &sig_handler; for (i=0; i<64; i++) if (sigaction(i, &sa, NULL) < 0) fprintf(stderr, "Can't listen to signal %d\n", i); fprintf(stderr, "Entering infinite loop\n"); while (1) sleep(999); } ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox will not run any other binary - configuration issue on my end
On 3/12/2013 1:39 PM, Paul Smith wrote: On Tue, 2013-03-12 at 12:35 -0400, q5sys wrote: however when I try to start any other program, like another shell for example, zsh, bash, etc. Busybox returns that the command is not found. The kernel tries to invoke the proper ld.so but can't find it, so it gives this very cryptic error message. The short version: You're probably trying to run a dynamic-linked program and missing a library. Run "ldd" to find out. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: BeagleBone for ALSA & jackd
On 10/24/2012 8:53 AM, Grant wrote: I would like to build as minimal of a system as possible on a BeagleBone. I only need ALSA and jackd to work. Would this work well with busybox? I'm very familiar with Gentoo but a system like this would be set up entirely outside of the Gentoo framework? Gentoo makes for a great system to create lightweight builds. You can build a minimal build with something like: ROOT=/tmp/somewhere emerge -v baselayout uclibc busybox The details are slightly more complex, eg I tend to use a uclibc based chroot with hardened compiler, etc, you will need a cross compiler setup, but very roughly that's about all you need... I already have Gentoo on an SD card running on the BeagleBone so I wouldn't need a cross compiler. Could I do the above, copy /tmp/somewhere to / on another SD card, set up /boot, and boot? It couldn't be so easy :) Well, this is on the verge of being more appropriate for the Gentoo forums, but I figured I'd mention my technique for building my busybox-based car computer. Start by building busybox (statically linked), and building a system image consisting of a standard directory tree, a bunch of busybox hardlinks, and a small handfull of files in /etc. Find any Linux that runs on your target platform. Steal their kernel. (and needed modules) Make it boot. (have to write your own init scripts. I suggest "runit" since it's built into busybox, but perp and s6 are also nice) You now have a bootable Linux system in the ballpark of 4MB. Get a Gentoo stage-3 image for your platform. For best results, put the stage-3 image on a nice file server and NFS-mount it onto the target platform. (which is a little involved, but worth it, IMHO. This gives you an easy way to make backups and copies or even add it to version control.) chroot into it and emerge all the packages you need. (trying to do the same on x86 and cross-compiling will waste a bunch of your time and drive you slightly insane, unless you enjoy debugging autoconf scripts) Once you have the chrooted Gentoo system behaving as you like, write a perl script that copies out *only* the files you need, (excluding binaries replaced by busybox) and place them into the mostly-empty system you created earlier. Gentoo has the nice /var/db/pkg files to help you find all of a package's files. Exclude packages like baselayout. Then exclude some directories like /etc and /usr/share/doc. (you want to very carefully craft your own /etc) Then take the result and copy it to a USB stick, and boot off of it. For bonus points, take the result and play the symlink-to-tmpfs game and then make the image a read-only squashfs image, and use that as the system root. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Chroot in ftpd on newer kernel versions
On 10/3/2012 3:56 PM, Harald Becker wrote: Hi Sven-Göran ! I think wrapping ftpd in tcpsvd would do that? Something like: tcpsvd -Eu USER[:GRP] 0.0.0.0 21 ftpd /path/to/ftp/pub This is the way I tried to call ftpd, but this way the user privileges are dropped before ftpd tries to do the chroot. Chroot by none root users is prohibited in (at least) newer Linux kernel. So if you drop user privileges before yo do the chroot you are not able to do it afterwards. Either tcpsvd needs to do the chroot before dropping user privileges (IMO a great feature, as other applets/applications may benefit from having a chroot capable tcpsvd) or ftpd has to handle the user change. Actually, take a look at the "chpst" utility included in busybox. It can chroot and drop privileges before 'exec'ing ftpd. In fact, that utility might just be the answer to your whole thread. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Add xorpipe utility
On 9/12/2012 10:42 PM, j...@jodybruchon.com wrote: My rationale behind writing this simple utility is as follows: Moving data through a fully encrypted tunnel like SSH is too slow for me, so I use netcat/socat for moving large chunks of data between systems. I don't want the data to be easily identified and reproduced if it is somehow intercepted, though it's also not a major problem if someone goes through the trouble of decrypting it; thus, simple XOR encryption is good enough for my purposes and is also extremely fast. I'm sure someone else will find it useful, and given its minuscule size, it is of negligible cost to include. I apologize for further sidetracking the conversation, but if I were going to write a quick-n-dirty encryption tool I would pick a 32-bit int and then XOR with a pseudo-random sequence generated from it. That would at least give the attacker a mental challenge (unless they knew the first 4 bytes of the data...) Maybe also add a salt parameter? while (more_data) { data[i]= data[i] ^ key ^ salt; key= key * a + c; } (http://en.wikipedia.org/wiki/Linear_congruential_generator) Integer multiplication is pretty cheap on most hardware. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [vamos-dev] [PATCH 1/3] fix literal error warning
On 9/10/2012 12:36 PM, Michael Conrad wrote: On 9/10/2012 11:46 AM, Michael Tokarev wrote: On 10.09.2012 19:31, Manuel Zerpies wrote: Hey guys, what about this patch? Is there anyone who can have a look at it? [] -bb_perror_msg(filename); +bb_perror_msg("%s", filename); Please stop fixing a non-issue. This GCC warning is wrong. This has been discussed several times, and exactly the same patch has been proposed several times too. Actually, that half of his patch *is* legitimate. It's a bug. $ ./busybox stat -f "%s" stat: (null): No such file or directory Furthermore, it could potentially be used in an exploit. Suppose someone has a CGI script that runs "stat -f" on a requested file, and an attacker can see the error output. The attacker can inspect the stack using "%d %d %d %d %d %d..." and then maybe find a suitable pair of integers in the stack for "%.*s", which could be used to dump out the memory of the busybox process, either to prepare a different exploit, or to possibly dump environment variables containing passwords or configuration settings. Luckily, it only affects SELINUX platforms. (oh the irony) ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [vamos-dev] [PATCH 1/3] fix literal error warning
On 9/10/2012 11:46 AM, Michael Tokarev wrote: On 10.09.2012 19:31, Manuel Zerpies wrote: Hey guys, what about this patch? Is there anyone who can have a look at it? [] - bb_perror_msg(filename); + bb_perror_msg("%s", filename); Please stop fixing a non-issue. This GCC warning is wrong. This has been discussed several times, and exactly the same patch has been proposed several times too. Actually, that half of his patch *is* legitimate. It's a bug. $ ./busybox stat -f "%s" stat: (null): No such file or directory It's only on the SELINUX enabled binary. Here's the full context: #if ENABLE_SELINUX security_context_t scontext = NULL; if (option_mask32 & OPT_SELINUX) { if ((option_mask32 & OPT_DEREFERENCE ? lgetfilecon(filename, &scontext) : getfilecon(filename, &scontext) ) < 0 ) { bb_perror_msg(filename); return 0; } } #endif if (statfs(filename, &statfsbuf) != 0) { bb_perror_msg("can't read file system information for '%s'", filename); return 0; } ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
busybox@busybox.net
On 09/07/12 01:00, Rich Felker wrote: > On Fri, Sep 07, 2012 at 06:50:48AM +0200, Harald Becker wrote: >> Sorry if it sound provocative, I'm just interested/wondering what/why >> are you doing here. Nothing more. > I'm not doing it. I'm just uncomfortable with having a shell that will > misinterpret conforming, albeit obfuscatd, shell scripts from third > parties, and was giving one such example. I suspect the main place > such code might come from a is a script that obfuscates and/or removes > all unnecessary whitespace from a given shell script. > Would you happen to be the poor sucker tasked with writing that tool? I feel for you :-) A tool like that would be up against all the deviations from the standard that occur on countless shell versions throughout history that exist across different flavors of UNIX. Just look at the autoconf project- they don't even use functions, for sake of compatibility. Also keep in mind that the standard was created long after the shells, in an attempt to move them toward a common syntax. Also, I think such a tool would have to handle Bash anyway, since it's one of the most prevalent shells out there. (also a number of distros have bash masquerade as sh, which *should* make it conform to POSIX, if you're lucky) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: httpd w/PHP performance
On 6/21/2012 6:01 AM, Laurent Bercot wrote: I have an application that runs well using lighttpd with PHP. In an effort to reduce the memory footprint I tried porting it to the busybox ( 1.20.1 ) httpd. It was easy to get this working and it seems to work properly. What isn't good enough is performance when executing PHP scripts. It looks like the httpd is using fork/exec for each cgi, and that fork/exec can use a lot of CPU. httpd itself, and on a fast machine with a decent OS, fork/exec themselves, don't use *that* much CPU. I suspect that your bottleneck might be the startup time of the PHP interpreter, since busybox httpd is indeed spawning a new PHP intepreter per request. $ time perl -e '$i=1000; system("sh","-c","") while $i--;' real0m1.213s user0m0.004s sys 0m0.120s $ time perl -e '$i=1000; system("perl","-e","") while $i--;' real0m1.845s user0m0.012s sys 0m0.112s $ time perl -e '$i=1000; system("ruby","-e","") while $i--;' real0m35.341s user0m28.954s sys 0m3.176s $ time perl -e '$i=1000; system("php","empty.php") while $i--;' real2m25.559s user2m18.189s sys 0m6.000s This is probably because PHP doesn't use modules, and links to *everything* it has compiled support for. PHP is linked against 41 libraries on my system. The startup cost is probably just the dynamic linking and initialization of libraries. (To be fair, other scripting languages would take longer to load than PHP if you loaded all those modules.) George: you might want to try recompiling php with the minimum features needed for your application, and maybe linking with uClibc . It will help in the CGI case, but also help your memory usage if you use lighttpd and a pool of php processes. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: httpd w/PHP performance
On 6/21/2012 8:39 AM, Gary Altenberg wrote: On 6/21/2012 5:01 AM, Laurent Bercot wrote: There might also be some downsides to repeated alloc/free in the embedded environment. Not at all. As long as you have enough memory to serve the requests, and dynamic allocations are kept to a reasonable level, there's no problem in performing several of them in an embedded environment. If anything, the fork+exec approach makes memory management easier on the programmer (and on the kernel to some extent) since every exec and every process death trigger automatic garbage collection for the late process. Doesn't this depend on what CPU you are using? If you are using a NO MMU CPU doesn't a lot of alloc/free calls leave your memory very fragmented? Not if you free *everything* when you're done. (It's a moot point anyway, since PHP runs every request with a fresh variable-space, and the strategies of "deallocate everything" and "exit/fork-a-new-process" are nearly identical) ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Mounting Filesystem over existing directory
On 06/04/2012 10:06 AM, Laurent Bercot wrote: >> Is that correct. In my system i can update the kernel boot args. But i >> believe that if the mounting of the root partition fails then the >> kernel will panic. > You can do some basic tests before rebooting, including whether the > mounting works (mount /dev/something /mnt/test) and whether the new > firmware looks like something you actually made > (chroot /mnt/test /bin/true && /bin/verify /mnt/test/somepublickey) > > If all else fails, you should have a hardware watchdog that reboots > the device when the kernel's gone fishing, and your bootloader will > then fall back on the old rootfs. > I would think you'd want to use kexec to test the new image, then if it panics, the nvram is unchanged and it will reboot into the regular partition. If the kexec'd system boots up, and knows that it is testing an update, then it can be the one to write the changes to the nvram so that it is used from now on. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Mounting Filesystem over existing directory
On 6/1/2012 2:42 AM, Laurent Bercot wrote: Out of curiosity, Is is possible to free up the resources used by initramfs. I would be very interested in knowing how this can be done. Initramfs is really just a tmpfs which the kernel copies files into at boot-time. You free it by removing all files from it, and unmounting it (after switch_root, because you can't unmount "/"). My initramfs was only 5MB (busybox, rsync, dropbear-sshd, some symlinks and a script) so I didn't care. I want busybox loaded into ram for the entire life of the system, so I could just "rm" the others to reclaim a tiny bit of ram and that's pretty much optimal for me. In my case, i am developing a system for an embedded system with NAND storage. Due to NAND corruption issues that mostly arise right now is when system is powered off while NAND writes are being performed (i.e. when files are being flushed out to the filesystem). This corruption makes the system un-bootable. Due to this issue i want to make the NAND filesystem readonly. Only at the time of system updates the filesystem will be remounted in rw mode. This still leaves room for the corruption to occur during system updates. There's only one way to guarantee bootability even with updates: have *two* read-only partitions for the rootfs. Boot on one; when you download an update, write the binary file to the other one. Reboot. If it boots, use the new partition as your new rootfs; if not, fall back on the old one (it still works) and report a failure. Right now i am thinking of having a initramfs filesystem with a recovery system that starts a device recovery process if the system partition cannot be mounted. So the intention is: You can do that, but that means your device will be non-functional (i.e. stuck in recovery mode) at the first failing update. (And trust me, failing updates WILL happen.) Your users will complain, and rightfully so. Better have two rootfs partitions so you can always guarantee that one of them boots into a functional system. Interesting. But where do you have the logic for choosing a boot device? What if your new partition is fine, but core services fail to load? How do you recognize that you need to start over with a different root partition? My case is also an embedded system. I just wanted reliability, system updates from USB drive, and the ability to power-off the system without notice (thus mounting read-only). My init script mounts all the USB devices looking for a system update (squashfs file), and if it finds one it mounts the main partition read/write and uses rsync to copy the image to the local drive, then unmounts everything. Then, it mounts the main partition read-only, creates the union, and execs 'init'. In practice, it runs very fast, especially if no USB devices are present. If anything goes wrong with the new version, I just pop in a USB drive with the old version. The initramfs is simple enough that it never needs changed. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Mounting Filesystem over existing directory
On 5/31/2012 2:04 AM, Bartos-Elekes Zsolt wrote: Michael Conrad wrote: Unionfs has one problem though: the only way to get correct behavior is to merge path A and B onto mountpoint C. (C can't be the same as A or B). Perhaps this is valid only for older versions of unionfs. I am using unionfs mounted on /var that is composed of a tmpfs mounted on /mnt/tmpfs, and the original /var that is on the flash (containing only a few important files and directories that must be preserved across reboots, like /var/lib/dpkg). $ mount | grep "unionfs" unionfs on /var type unionfs (rw,relatime,dirs=/mnt/tmpfs=rw:/var=rw) ... On 6/1/2012 3:24 AM, Sameer Naik wrote: With UnionFS-2.5.11 i could merge /var/cache/etc=rw and /etc=ro at /etc. But evidently i have no real world testing going on here. Is there any specific test case i should try to confirm this? I think I was remembering it wrong. I think my actual problem was because I was trying to put the union on "/", and so the source of the union was *under* the mount-point. And who knows, this might work now too. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Mounting Filesystem over existing directory
On 5/30/2012 3:08 AM, Sameer Naik wrote: Thanks for the quick response. I will check out the links Bartos provided. Certainly, my query is not related to busybox, but where else can i find a better community for my query :) Regards ~Sameer Indeed, you're posting your question to a lot of people who have done this exact thing :-) I found aufs to be more experimental with lots of fancy features... but wasn't stable enough for me. (this changes over time and by kernel version, of course, but when I tested it 3 years ago I got some strange results) Unionfs has worked flawlessly for me on multiple kernels. Unionfs has one problem though: the only way to get correct behavior is to merge path A and B onto mountpoint C. (C can't be the same as A or B). What I came up with was to use the rootfs that Linux creates for the initramfs, and have the following symlink pattern: /etc -> /union/etc /bin -> /union/bin ... /union/etc -> /initrd/etc /union/bin -> /initrd/bin ... All of that lives in the initramfs and is loaded immediately. Then, I mount the system image at /sysimage, and then mount -t unionfs -o dirs=/initrd=rw:/sysimage/fhs=ro none /union || die "Failed to set up unionfs"; This hides the second level of symlinks and uses the unionfs *atomically*, and since I'm using the rootfs, I don't have to mount my own tmpfs or switchroot or anything like that. Also, my system uses the one busybox binary that it loaded out of initramfs for the entire life of the system, so no need to worry about freeing up the resources used by the initramfs. Also, the entire system becomes writable, and if I want to know what I changed I can just rsync /initrd to my development machine and see what new files exist, and integrate them into my next system image. I can also selective revert things to default while the system is running by deleting files out of /initrd. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Possible change to /etc/mdev.conf default?
On 05/14/2012 01:45 AM, Walter Dnes wrote: > On Sun, May 13, 2012 at 05:47:15PM -0600, Michael J. Hammel wrote >> On Sun, 2012-05-13 at 18:14 -0400, Walter Dnes wrote: >>> I was spelunking through my /etc/mdev.conf, looking at the syntax, >>> when something occured to me looking at... >>> >>> sr[0-9]*root:cdrom 660 @ln -sf $MDEV cdrom >>> >>> What happens if you have multiple devices, e.g. "sr0" and "sr1"? Does >>> the system get confused? Would the following work better... >>> >>> sr[0-9]*root:cdrom 660 @ln -sf $MDEV cdrom%1 >> I don't think mdev handles that syntax but it would be trivial to >> replace the ln command with a script that simply parses the number >> (sr) from MDEV and performs the same function as you suggest. > Out of sheer curiousity, what do %1 and %2 do as shown on > http://git.busybox.net/busybox/plain/docs/mdev.txt which seems to be > somewhat different from the default /etc/mdev.conf on my machine. > FEATURE_MDEV_RENAME_REGEXP mdev *does* do what you want. Notice that you need parentheses (like in the example) for regex capturing. (and the feature needs to be enabled of course) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: OTP feature for /bin/login
On 5/8/2012 6:56 PM, Rich Felker wrote: On Tue, May 08, 2012 at 05:38:26PM -0400, Michael Conrad wrote: With the little amount of thought I've done on it so far, I've concluded that a viable system would have to have executables instead of shared objects as atoms, i.e. the /bin/login program configurably executes into /bin/login-X-mechanism, where X can be passwd, OTP or anything of the kind, and /bin/login-X-mechanism does the X-specific work. +1 Call them "Busybox Auth Helpers" and the API is as simple as read "$username\n$password\n" from stdin, and return 0 or 1. Serves everyone's needs in about 20 lines of code added to busybox. All configuration and selection of which accounts are affected can be written into a Multiplexor which obeys the same API. You could even write an auth helper that dynamically links out to PAM. A *good* OTP system (I'm not sure how good the submitted one is) needs bidirectional communication for login. For a printed sheet of passwords, the host has the ask the user for a specific number off the sheet, not just any password, so the authentication method needs a way to present this information to the user. Or if you have a device on the client side that can generate passwords based on a challenge from the host, you need a way to present the challenge to the user when they attempt to login (so they can enter it in their device). My thought here was that you can't always alter the original protocol that much (httpd, ftpd, etc). If you can and need to, then you might as well just write a custom daemon (which actually, is exactly what you're describing below with the ssh passthrough) or use PAM. Writing a one-size-fits-all authentication API is not a simple thing, and I think any attempt to do so would end up as complex as PAM. The OP was describing a system where you'd have your phone time-synchronized with the server, and be unidirectional. Your phone knows what the correct password is at any given time. It could be as simple as checking getenv("BUSYBOX_AUTH_HELPER"), or hard-coded busybox config string. If it doens't exist, fall back to passwd/shadow. Letting this be configured by the environment is a gaping security hole... I was about to say "not any worse than LD_LIBRARY_PATH", but I suppose then it would need the same special restriction for setuid programs. (It would just require a check of geteuid... but you're right, probably better to forget it and either use a config file or hard-code it.) -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: OTP feature for /bin/login
On 5/8/2012 9:40 AM, Laurent Bercot wrote: May be PAM is the de facto standard, but what about those whose do not like to use PAM on there systems (as they consider them bloated)? Then we need a lightweight PAM replacement. I've managed to avoid thinking about it too much so far, but if people want to add different auth mechanisms to busybox, this is the way to go. What rubs me the wrong way with PAM is that it requires dynamic linking, since it relies on .so and dlopen() mechanisms. There's no way to have a complete PAM-enabled system with statically linked binaries. With the little amount of thought I've done on it so far, I've concluded that a viable system would have to have executables instead of shared objects as atoms, i.e. the /bin/login program configurably executes into /bin/login-X-mechanism, where X can be passwd, OTP or anything of the kind, and /bin/login-X-mechanism does the X-specific work. +1 Call them "Busybox Auth Helpers" and the API is as simple as read "$username\n$password\n" from stdin, and return 0 or 1. Serves everyone's needs in about 20 lines of code added to busybox. All configuration and selection of which accounts are affected can be written into a Multiplexor which obeys the same API. You could even write an auth helper that dynamically links out to PAM. It could be as simple as checking getenv("BUSYBOX_AUTH_HELPER"), or hard-coded busybox config string. If it doens't exist, fall back to passwd/shadow. On 5/8/2012 4:22 PM, Guylhem wrote: IMHO it follows the spirit of busybox, so the current implementation was submitted since already covers most of the needs as it. Writing a minimal implementation of OTP **as an applet** would certainly be in the spirit of busybox. Adding extra feature-specific behavior to existing applets IMHO is not. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Dangerous behaviour of mktemp when unknown flags are used
On 04/17/2012 02:30 PM, Rich Felker wrote: > On Tue, Apr 17, 2012 at 03:48:20PM +0200, Denys Vlasenko wrote: >> On Tue, Apr 10, 2012 at 4:24 AM, John Spencer >> wrote: >>> (this is busybox 1.19.2) >>> >>> /src/build/zlib-1.2.6/Makefile:tempfile := $(shell mktemp -u __XX) >>> >>> mktemp: illegal option: u >>> BusyBox v1.19.2 (2012-04-08 20:17:39 GMT) multi-call binary. >>> >>> Usage: mktemp [-dt] [-p DIR] [TEMPLATE] >>> >>> >>> >>> zlibs Makefile uses mktemp -u without testing if it returns a result and >>> then happily uses the variable to delete and create stuff. >>> >>> i don't think it's a good idea that the binary doesn't ignore (or only warn >>> about the wrong config on stderr) and still return some usable string to the >>> caller. >> It doesn't return anything: >> >> $ busybox mktemp -u 2>/dev/null >> >> $ >> >> The entire output went to stderr. None is on stdout. >> This is as correct handling of unknown option as it can get. > That's the entire issue he was reporting. Since the normal usage of > mktemp with -u is something like var=$(mktemp -u), it's very dangerous > for the output to be an empty string. It's possible to check for > errors, and one probably should, but plenty of low-quality scripts > don't and the shell does not make it particularly easy to do so. (The > simplest solution I can think of for a script would be > > var=$(mktemp -u || echo /dev/null/invalid/path) > > where the fallback is chosen to be something that's guaranteed by > POSIX not to work. Considering that mktemp has an inherent possibility of failure, I think checking failure of the command is the *only* correct usage. And it isn't hard at all: You can check $? or test the length of the variable or set a default on the next line. Makefile are less convenient, but as you showed, it isn't hard. Also, why is it so dangerous? It doesn't exist, so you have to create it, and mkdir and touch and shell redirection all fail with a missing argument. (ending the make process, if you've written the makefile correctly) and you'll have a handy message on stdout to help you find the problem. -Mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox