Re: [LEDE-DEV] [PATCH 1/2] [ubox] syslog: use realloc to change log buffer size
On 18/05/2016 16:08, Conor O'Gorman wrote: > On 18/05/16 15:03, Dan Bugnar wrote: >> For the larger size it takes the distance from the old log and newest >> and added to _log to have the new newest, same for the oldest. It >> doesn't matter if the newest > oldest OR oldest > newest. > If the oldest > newest, there will be a blank area, the new space. How > will this be handled during log printing? > >> And if the size is smaller than we will have a fresh new smaller >> buffer with the newest and oldest pointing to _log(start). >> >> If it is possible that a message is added to the old log after the >> realloc call is done and the log doesn't point to the new buffer, we >> will loose that message. > For both of these situations, it is possible to lose messages. I thought > the intention was not to lose messages? > > Conor > i see it the same way. please check the code and make sure it covers all cases. 2/2 looks good but i just marked the series as "Changes requested" please explain in V3 how you addressed the issue of reallocating the buffer. John > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] v2: block.c: Add support for checking vfat filesystems
On 16-05-19 02:07 AM, John Crispin wrote: > > > On 18/05/2016 13:28, l...@daniel.thecshore.com wrote: >> From: Daniel Dickinson >> >> v2: Fix mixup of dosfsck checking ext* and e2fsck checking vfat. >> >> vfat is a common filesystem which users may want to mount on an >> OpenWrt/LEDE device, so support peforming filesystem checks >> before mount for vfat. > > has this series been test on device and did you verify that the fs check > now works properly for both those filesystems ? Not yet, will let you know when. Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] v2: block.c: Add support for checking vfat filesystems
On 18/05/2016 13:28, l...@daniel.thecshore.com wrote:
> From: Daniel Dickinson
>
> v2: Fix mixup of dosfsck checking ext* and e2fsck checking vfat.
>
> vfat is a common filesystem which users may want to mount on an
> OpenWrt/LEDE device, so support peforming filesystem checks
> before mount for vfat.
has this series been test on device and did you verify that the fs check
now works properly for both those filesystems ?
John
>
> Signed-off-by: Daniel Dickinson
> ---
> block.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/block.c b/block.c
> index 71ffd0b..5a584cb 100644
> --- a/block.c
> +++ b/block.c
> @@ -628,24 +628,30 @@ static void check_filesystem(struct blkid_struct_probe
> *pr)
> pid_t pid;
> struct stat statbuf;
> const char *e2fsck = "/usr/sbin/e2fsck";
> + const char *dosfsck = "/sbin/dosfsck";
> + const char *ckfs;
>
> /* UBIFS does not need stuff like fsck */
> if (!strncmp(pr->id->name, "ubifs", 5))
> return;
>
> - if (strncmp(pr->id->name, "ext", 3)) {
> + if (!strncmp(pr->id->name, "vfat", 4)) {
> + ckfs = dosfsck;
> + } else if (!strncmp(pr->id->name, "ext", 3)) {
> + ckfs = e2fsck;
> + } else {
> ULOG_ERR("check_filesystem: %s is not supported\n",
> pr->id->name);
> return;
> }
>
> - if (stat(e2fsck, &statbuf) < 0) {
> + if (stat(ckfs, &statbuf) < 0) {
> ULOG_ERR("check_filesystem: %s not found\n", e2fsck);
> return;
> }
>
> pid = fork();
> if (!pid) {
> - execl(e2fsck, e2fsck, "-p", pr->dev, NULL);
> + execl(ckfs, ckfs, "-p", pr->dev, NULL);
> exit(-1);
> } else if (pid > 0) {
> int status;
>
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] toolchain: Bump ARC tools to arc-2016.03
This change switches ARC tools to the most recent arc-2016.03
version.
ARC GNU tools of version arc-2016.03 bring some quite significant
changes like:
* Binutils v2.26+ (upstream commit id 202ac19 with additional ARC
* patches)
* GCC v4.8.5
* GDB 7.10
More about changes, improvements and fixes could be found here:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03
Signed-off-by: Alexey Brodkin
---
toolchain/binutils/Config.in| 8
toolchain/binutils/Config.version | 4 ++--
toolchain/binutils/Makefile | 8
.../patches/arc-2016.03/200-arc-fix-target-mask.patch | 13 +
toolchain/gcc/Config.version| 2 +-
toolchain/gcc/common.mk | 8
.../001-revert_register_mode_search.patch | 0
.../{arc-2015.06 => arc-2016.03}/002-weak_data_fix.patch| 0
.../003-universal_initializer.patch | 0
.../{arc-2015.06 => arc-2016.03}/004-case_insensitive.patch | 0
.../{arc-2015.06 => arc-2016.03}/010-documentation.patch| 0
.../{arc-2015.06 => arc-2016.03}/020-no-plt-backport.patch | 0
.../{arc-2015.06 => arc-2016.03}/100-uclibc-conf.patch | 0
.../210-disable_libsanitizer_off_t_check.patch | 0
.../800-arc-disablelibgmon.patch| 0
.../{arc-2015.06 => arc-2016.03}/820-libgcc_pic.patch | 0
.../850-use_shared_libgcc.patch | 0
.../{arc-2015.06 => arc-2016.03}/851-libgcc_no_compat.patch | 0
.../{arc-2015.06 => arc-2016.03}/860-use_eh_frame.patch | 0
.../{arc-2015.06 => arc-2016.03}/870-ppc_no_crtsavres.patch | 0
.../{arc-2015.06 => arc-2016.03}/880-no_java_section.patch | 0
.../{arc-2015.06 => arc-2016.03}/910-mbsd_multi.patch | 0
.../920-specs_nonfatal_getenv.patch | 0
.../940-no-clobber-stamp-bits.patch | 0
toolchain/gdb/Makefile | 6 +++---
.../100-no_extern_inline.patch | 4 ++--
.../{arc-2015.06-gdb => arc-2016.03}/110-no_testsuite.patch | 4 ++--
.../120-fix-compile-flag-mismatch.patch | 2 +-
.../gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch | 13 +
29 files changed, 49 insertions(+), 23 deletions(-)
create mode 100644
toolchain/binutils/patches/arc-2016.03/200-arc-fix-target-mask.patch
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/001-revert_register_mode_search.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/002-weak_data_fix.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/003-universal_initializer.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/004-case_insensitive.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/010-documentation.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/020-no-plt-backport.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/100-uclibc-conf.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/210-disable_libsanitizer_off_t_check.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/800-arc-disablelibgmon.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/820-libgcc_pic.patch
(100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/850-use_shared_libgcc.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/851-libgcc_no_compat.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/860-use_eh_frame.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/870-ppc_no_crtsavres.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/880-no_java_section.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 => arc-2016.03}/910-mbsd_multi.patch
(100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/920-specs_nonfatal_getenv.patch (100%)
rename toolchain/gcc/patches/{arc-2015.06 =>
arc-2016.03}/940-no-clobber-stamp-bits.patch (100%)
rename toolchain/gdb/patches/{arc-2015.06-gdb =>
arc-2016.03}/100-no_extern_inline.patch (91%)
rename toolchain/gdb/patches/{arc-2015.06-gdb =>
arc-2016.03}/110-no_testsuite.patch (73%)
rename toolchain/gdb/patches/{arc-2015.06-gdb =>
arc-2016.03}/120-fix-compile-flag-mismatch.patch (85%)
create mode 100644
toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
diff --git a/toolchain/binutils/Config.in b/toolchain/binutils/Config.in
index c32f43c..2960c94 100644
--- a/toolchain/binutils/Config.in
+++ b/toolchain/binutils/Config.in
@@ -3,7 +3,7 @@
choice
prompt "Binutils Version" if TOOLCHAINOPTS
default BINUTILS_USE_VERSION_2_25_1 if !arc
- default BINU
Re: [LEDE-DEV] [PATCH RFC 2/2] x86: lift generic x86-32 target
I built an openwrt image for apu2 back in March. It mostly just worked, with some minor tweaks for running off of mmc, This was my patch then, relative to r49096. diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/config-4.4 index 5b54031..e323fa6 100644 --- a/target/linux/x86/config-4.4 +++ b/target/linux/x86/config-4.4 @@ -270,6 +270,14 @@ CONFIG_M486=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set +CONFIG_MMC=y +CONFIG_MMC_BLOCK=y +CONFIG_MMC_RICOH_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PCI=y +# CONFIG_MMC_SDHCI_PLTFM is not set +# CONFIG_MMC_TIFM_SD is not set +# CONFIG_MMC_WBSD is not set # CONFIG_MODIFY_LDT_SYSCALL is not set CONFIG_MODULES_TREE_LOOKUP=y CONFIG_MODULES_USE_ELF_REL=y On Wed, May 18, 2016 at 4:17 PM, Stijn Tintel wrote: > On 17-05-16 23:37, Felix Fietkau wrote: >> On 2016-05-17 23:12, Daniel Golle wrote: >>> * build for pentium4 instead of i486 >>> * enable PAE >>> * enable EFI support >>> * enable KVM guest and host support > Is anyone running KVM on a 32bit host? I would leave out KVM host > support here. >> I like this change, but I think I'll wait a bit before applying it to >> see if anybody else has some comments about it. >> > I too think x86 and subtargets need some love, but let's not rush > things. Maybe now is a good time to discus other things related to x86 > as well. > > E.g., a while ago I created a profile for x86/64 for the PCEngines APU2, > but never submitted it, so I put it at [1] now. Last year, on > OpenWrt-Devel, Felix suggested [2] instead. I would like to hear others' > opinions about this too. > > And if any else has other ideas... Looking forward to hear them. > > Stijn > > [1] > https://git.lede-project.org/?p=lede/stintel/staging.git;a=shortlog;h=refs/heads/apu2 > [2] > https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037035.html > > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH RFC 2/2] x86: lift generic x86-32 target
On 17-05-16 23:37, Felix Fietkau wrote: > On 2016-05-17 23:12, Daniel Golle wrote: >> * build for pentium4 instead of i486 >> * enable PAE >> * enable EFI support >> * enable KVM guest and host support Is anyone running KVM on a 32bit host? I would leave out KVM host support here. > I like this change, but I think I'll wait a bit before applying it to > see if anybody else has some comments about it. > I too think x86 and subtargets need some love, but let's not rush things. Maybe now is a good time to discus other things related to x86 as well. E.g., a while ago I created a profile for x86/64 for the PCEngines APU2, but never submitted it, so I put it at [1] now. Last year, on OpenWrt-Devel, Felix suggested [2] instead. I would like to hear others' opinions about this too. And if any else has other ideas... Looking forward to hear them. Stijn [1] https://git.lede-project.org/?p=lede/stintel/staging.git;a=shortlog;h=refs/heads/apu2 [2] https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037035.html ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] rocket cwmp - open tr-069 client for embedded platforms
Hi all! prpl Foundation has made the invitation to propose OpenWrt enhancement ideas which may end up funded by the same organization [1]. With this email I'm offering to prpl Foundation to fund Rocket CWMP project - which is the client implementation of CWMP / TR-069 protocol. Since this is a good opportunity to further extend OpenWrt functionality I'm adding several other mailing lists in CC and hope to initiate discussions regarding this proposal and project. CWMP (TR-069) [2] has a very important role both for ISP and for the entire ecosystem with manufacturers included. The standard form of CWMP was primarily developed for a number of Internet access devices, such as modems, set-top boxes, VolP phones and routers. TR-069 standardizes the wide area network (WAN) management of CWMP devices and gives Internet Service Providers a framework and a common language to remotely provision and manage these devices regardless of device type or manufacturer. There are around twenty TR-* documents which mostly define new parameters or extend the RPC (Remote Procedure Call) methods. CWMP (CPE WAN Management Protocol), sometimes called TR-069 (Technical Report 069), is a technical specification of a Broadband Forum designed for remote governing of CPE (Customer Premises Equipment). Seeing that CWMP is a standardized, text based protocol which offers a communication between CPE and Auto Configuration Servers (ACS), it can be used between different equipment manufacturers. Couple of years back I've authored the first Open Source TR-069 client specifically targeting OpenWrt - it was named freecwmp [3]. Since then I've learned a lot of lessons and in the company, Sartura, the team has started developing new implementation which solves the limitations of the old implementation. If funded, we are going to use the budget to further improve existing codebase and of course to clean it up and prepare for Open Source release. In order to make this a success, we will work on the documentation, testing infrastructure and make it easy for vendors and hackers to use this project when needed. I'll be making Rocket CWMP presentation on the prplwrt meeting on May 19 (tomorrow). [4] These meetings are usually recorded and published on YouTube. I hope that will happen with this meeting as well in case somebody is interested but is not able to join. More information about the proposal can be found on the prpl Wiki [5] and in the proposal documentation [6][7]. Comments are welcome! Sincerely, Luka Perkov [1] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding [2] https://www.broadband-forum.org/cwmp.php [3] https://lists.openwrt.org/pipermail/openwrt-devel/2012-June/015655.html [4] http://lists.prplfoundation.org/pipermail/openwrt/2016-May/000544.html [5] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding/Rocket_CWMP [6] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-public.pdf [7] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-slides-public.pdf ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH RFC 2/2] x86: lift generic x86-32 target
Please keep CONFIG_PATA_ATIIXP=y I have several (very capable/low power/versatile) Fujitsu Futro S550 that need this so it can boot from the internal CF Card Regards Lucian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, 18 May 2016, Ferry Huberts wrote: On 18/05/16 11:10, David Lang wrote: On Wed, 18 May 2016, Ferry Huberts wrote: On 18/05/16 10:03, David Lang wrote: On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:46, Ferry Huberts wrote: already in-place in Fedora and RedHat/CentOS. You then get even stronger protection and run-time performance impact is negligible. the stuff i proposed has not runtime hit. selinux is simple to full SELinux's hit is for all intents and purposes zero as well nowadays. blown and hard to maintain. the idea would be to create a custom tailored solution for our requirements. That is why I prefer AppArmor, you don't have the interaction between different application configs that you do with SELinux, so you can focus on the specific application that you are concerned about. AppArmor is significantly less secure than SELinux. And with SELinux you don't need all the preloading stuff that was talked about, you can just declare which ports are allowed. tightly configured in expert hands, you are right. However, that's not the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll point out that if home users are familar with Linux, the odds are good that it's a flavor of Ubuntu that uses AA rather than Fedora that uses SELinux. (not worth much because the home user probably hasn't touched AA or SELinux) That should not be an argument to do one or the other. You should ask yourself how far you would want to go in securing a router. Personally, I would absolutely love a router with a tight SELinux policy since it protects me well from unsavory access from the outside. do all the compressed filesystems support the tagging needed by SELinux? what about external drives with FAT* or NTFS? FAT and NTFS do not support it AFAIK, but how is that a problem? You'd run SELinux on your internal filesystem. it's not uncommon for people to attach an external drive for more space, and then have stuff run off of that drive. If SELinux can't find the appropriate labels, does it deny or allow by default. One of the things that annoys me about SELinux is the fact that a daemon can behave differently depending on if it's started by init, or started by the root user. I've fielded a lot of problem reports because something worked fine when they tested it as root and then failed when init started the process (also as uid 0). I've also seen cases where the testing as root created a file/directory with a label that isn't allowed when the process is started by init, so they have to detect the problem and remove the file to let it be created in the correct context. For the compressed filesystems: I don't know, they will probably support it if they're good citizen Linux filesystems. not all linux filesystems support xattrs. How do you handle the possible need to re-label your files on a read-only filesystem? Don't know, but take a look at Android, it has SELinux enabled in enforcing mode (the strongest mode). android devices tend to have a lot more storage/ram than many routers. They also aren't running on read-only filesystems. what is the difference in kernel size (and tool size) between AA and SELinux? Don't know. For clarity (and for weaseling out): I read a snip of the discussion and wanted to offer another alternative, so that the discussion could consider it. And I think it's a good thing to bring up and discuss. I happen to dislike SELinux and would not have brought up AppArmor until after things were moved to not run as root in the first place. But I think it's a good discussion to have. I am not trying to shout you down, just raising concerns. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, 18 May 2016, Radu Anghel wrote: step 1. add users to /etc/passwd (in the pre/post-install script probably, trying to use same uid/gid as major distributions would be nice) I believe that most of the major distros don't allocate uid/gid numbers statically, they are allocated as the packages are installed in the system (with the exception of a small number in the minimal base system) I see arguments both ways, which is the issue I raised in a different thread. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] "block" fstools wishlist
Listing out a few things I've found with fstools package (Version: 2016-05-17-db5d39d48b9d9a77565015c1aafb3ef0d2925f02) I'm mostly still working on openwrt CC branch, but the issues _seem_ to be fstools related, not kernel related, though I'm happy to retest if necessary. Some of these I've discussed on irc with blogic and jow, others just here, posting them here for posterity as they're bigger than quick fixes on IRC. Further, this is largely an area I'm not really comfortable trying to hack up patches, they need to follow the style and direction of the project more than just my specific needs, so I can't post patches for any of these. * block mount mounts _and_ turns swap on. block umount only unmounts. Shouldn't it swapoff as well? * "block" anything can't have it's output captured. The checks in libubox: ulog.c:: ulog_defaults() detect the attempt at capturing the output as a !tty and write to syslog instead. * block doesn't handle hotplug. This is probably the biggest thing. This overlaps with the old and unmaintained "mountd" package, which blogic expressed interesting destroying/merging/combining with "fstools" This doesn't seem to be a problem for usb sticks, because the removal of the stick removes the entire device node well. However, an SD card in a slot maintains a /dev/sda entry even after the card is removed. "block info" will fail to see new block details if a partition was mounted, or as activated swap, and swap and mounts are not turned off when the card is removed. I wrote about various trials and tribulations with mountd vs block here https://lists.openwrt.org/pipermail/openwrt-devel/2016-February/039798.html and resolved that I would simply poll "block info" every couple of seconds. Unfortunately, that ended up being rather noticeable CPU load, so I'm still looking for neat ways of handling sdcards, and while mountd noticed disk changes, it failed at reliably mounting/unmounting, and most importantly, was and is clearly regarded as "not the right way" going forward. Desktop linux mostly solves this with udisks/udisks2, and at the moment, something functionally equivalent is rather missing from the lede user space world. Cheers, Karl P signature.asc Description: OpenPGP Digital Signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MPTCP
On 18/05/2016 17:41, Christian Huldt wrote: > I just built LEDE with MPTCP, but in order to get better integration I'm > reading > https://wiki.openwrt.org/doc/devel/patches#adding_or_editing_kernel_patches > > MPTCP is however associated with a bunch of lines in the kernel config, > is there a way to add some defaults there som that make kernel_config is > not necessary? > > And is there a way to make the patch only be applied if it is chosen in > make menuconfig? > > have a look at the files in package/kernel/linux/modules/*.mk they package modules and allow you to define which symbols are required. John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] MPTCP
I just built LEDE with MPTCP, but in order to get better integration I'm reading https://wiki.openwrt.org/doc/devel/patches#adding_or_editing_kernel_patches MPTCP is however associated with a bunch of lines in the kernel config, is there a way to add some defaults there som that make kernel_config is not necessary? And is there a way to make the patch only be applied if it is chosen in make menuconfig? signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] [ubox] syslog: use realloc to change log buffer size
On 18/05/16 15:03, Dan Bugnar wrote: For the larger size it takes the distance from the old log and newest and added to _log to have the new newest, same for the oldest. It doesn't matter if the newest > oldest OR oldest > newest. If the oldest > newest, there will be a blank area, the new space. How will this be handled during log printing? And if the size is smaller than we will have a fresh new smaller buffer with the newest and oldest pointing to _log(start). If it is possible that a message is added to the old log after the realloc call is done and the log doesn't point to the new buffer, we will loose that message. For both of these situations, it is possible to lose messages. I thought the intention was not to lose messages? Conor ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf
On 2016-05-18 15:59, Alexey Brodkin wrote: > Hi Felix, > > On Wed, 2016-05-18 at 15:49 +0200, Felix Fietkau wrote: >> On 2016-05-18 15:06, Alexey Brodkin wrote: >> > >> > Hi Felix, >> > >> > On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: >> > > >> > > On 2016-05-16 16:42, Alexey Brodkin wrote: >> > > > >> > > > >> > > > If an image gets built as an Elf there's a chance >> > > > it will be used by developers for debugging purposes. >> > > > In that case it's very helpful to keep debugging info >> > > > in that image. >> > > > >> > > > I would think that most OWRT-powered devices in production >> > > > will use some form of binary image for booting so Elf >> > > > flavours could be left a bit bulkier with more debug info >> > > > inside. >> > > > >> > > > Signed-off-by: Alexey Brodkin >> > > You can get the bulky one directly from the kernel source directory, and >> > > there is definitely some value in having stripped ELF binaries as well >> > > for devices that can load them. >> > Well indeed in kernel's source directory we have an unstripped elf. >> > But what happens at least in case of ARC we build only one kernel's elf >> > and then as a post-built step we patch in .dtb for all boards we build >> > OWRT. >> > >> > In other words in "bin/arc770-uClibc" folder I have: >> > 1) openwrt-arc770-generic-axs101-initramfs.elf >> > 2) openwrt-arc770-generic-nsim_700-initramfs.elf >> > >> > Both are stripped but work as they are on the corresponding boards. >> > >> > In >> > "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" >> > I have perfectly unstripped vmlinux but it won't work on either board >> > because of >> > missing device tree blob. >> > >> > That means if one wants to get image for a board X with debug symbols he >> > or she >> > will need to do manual patching in of .dtb. Which is not the most >> > convenient thing ever. >> It's a lot simpler than that: You can boot the stripped and patched elf >> image from bin/ and use the vmlinux from the kernel source for the >> debugger afterwards. They are fully compatible. > > Good point. So indeed if we do want stuff in "bin/" folder to be stripped > that seems to be the simplest approach. > > But what if we with addition of another config option: > a) toggle kernel's CONFIG_DEBUG_INFO There's a config option for that already, and it's enabled by default. > b) use "--strip-unneeded" instead of currently used "-S" (which is an alias > to "--strip-all"). Why? - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf
Hi Felix, On Wed, 2016-05-18 at 15:49 +0200, Felix Fietkau wrote: > On 2016-05-18 15:06, Alexey Brodkin wrote: > > > > Hi Felix, > > > > On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: > > > > > > On 2016-05-16 16:42, Alexey Brodkin wrote: > > > > > > > > > > > > If an image gets built as an Elf there's a chance > > > > it will be used by developers for debugging purposes. > > > > In that case it's very helpful to keep debugging info > > > > in that image. > > > > > > > > I would think that most OWRT-powered devices in production > > > > will use some form of binary image for booting so Elf > > > > flavours could be left a bit bulkier with more debug info > > > > inside. > > > > > > > > Signed-off-by: Alexey Brodkin > > > You can get the bulky one directly from the kernel source directory, and > > > there is definitely some value in having stripped ELF binaries as well > > > for devices that can load them. > > Well indeed in kernel's source directory we have an unstripped elf. > > But what happens at least in case of ARC we build only one kernel's elf > > and then as a post-built step we patch in .dtb for all boards we build OWRT. > > > > In other words in "bin/arc770-uClibc" folder I have: > > 1) openwrt-arc770-generic-axs101-initramfs.elf > > 2) openwrt-arc770-generic-nsim_700-initramfs.elf > > > > Both are stripped but work as they are on the corresponding boards. > > > > In > > "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" > > I have perfectly unstripped vmlinux but it won't work on either board > > because of > > missing device tree blob. > > > > That means if one wants to get image for a board X with debug symbols he or > > she > > will need to do manual patching in of .dtb. Which is not the most > > convenient thing ever. > It's a lot simpler than that: You can boot the stripped and patched elf > image from bin/ and use the vmlinux from the kernel source for the > debugger afterwards. They are fully compatible. Good point. So indeed if we do want stuff in "bin/" folder to be stripped that seems to be the simplest approach. But what if we with addition of another config option: a) toggle kernel's CONFIG_DEBUG_INFO b) use "--strip-unneeded" instead of currently used "-S" (which is an alias to "--strip-all"). -Alexey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf
On 2016-05-18 15:06, Alexey Brodkin wrote: > Hi Felix, > > On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: >> On 2016-05-16 16:42, Alexey Brodkin wrote: >> > >> > If an image gets built as an Elf there's a chance >> > it will be used by developers for debugging purposes. >> > In that case it's very helpful to keep debugging info >> > in that image. >> > >> > I would think that most OWRT-powered devices in production >> > will use some form of binary image for booting so Elf >> > flavours could be left a bit bulkier with more debug info >> > inside. >> > >> > Signed-off-by: Alexey Brodkin >> You can get the bulky one directly from the kernel source directory, and >> there is definitely some value in having stripped ELF binaries as well >> for devices that can load them. > > Well indeed in kernel's source directory we have an unstripped elf. > But what happens at least in case of ARC we build only one kernel's elf > and then as a post-built step we patch in .dtb for all boards we build OWRT. > > In other words in "bin/arc770-uClibc" folder I have: > 1) openwrt-arc770-generic-axs101-initramfs.elf > 2) openwrt-arc770-generic-nsim_700-initramfs.elf > > Both are stripped but work as they are on the corresponding boards. > > In > "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" > I have perfectly unstripped vmlinux but it won't work on either board because > of > missing device tree blob. > > That means if one wants to get image for a board X with debug symbols he or > she > will need to do manual patching in of .dtb. Which is not the most convenient > thing ever. It's a lot simpler than that: You can boot the stripped and patched elf image from bin/ and use the vmlinux from the kernel source for the debugger afterwards. They are fully compatible. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/16 08:41, David Lang wrote: On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:04, David Lang wrote: The first question I would have is if we are going to the system users in an essentially random order (as needed so two systems with the same packages installed in a different order have different user->uid mapping) or if we are going to define service accounts distro wide so they are always going to be the same. what would be the pros and cons for either of those ? If you have static user allocations then LEDE needs to maintain a central repository of userids and a way for applications to be registered with it. If you have dynamic user allocations, then the package installer scripts need to have more complexity to request the userids on the fly and make everything they install have the correct permissions. (most distros take this approach) In the case of LEDE, we generally aren't running install scripts for the packages on a running system, all this happens at compile time when you don't have a way to run various tools to lookup and allocate users and set the file permissions, so I think there's a good argument that the static allocation approach would work better here. The other place where this bites people is when they have multiple systems that then need to start working together (mounting a network drive and sharing info, think high availability and similar, or copying files from one system to another and trying to use them there). The 'normal' answer is that you then need to start managing users with some new tool (Chef, Puppet, Ansible, Salt, etc) that pre-allocates the users onto the systems before the install scripts run and/or overrides the package defaults. As I say, the common choice is dynamically allocated uids, but lede has to do this at compile/image creation time instead of on a running system. I believe that during the root filesystem generation, scripts are run and some information is available. Dependencies and ordering may be an issue. Conor ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf
Hi Felix, On Wed, 2016-05-18 at 14:57 +0200, Felix Fietkau wrote: > On 2016-05-16 16:42, Alexey Brodkin wrote: > > > > If an image gets built as an Elf there's a chance > > it will be used by developers for debugging purposes. > > In that case it's very helpful to keep debugging info > > in that image. > > > > I would think that most OWRT-powered devices in production > > will use some form of binary image for booting so Elf > > flavours could be left a bit bulkier with more debug info > > inside. > > > > Signed-off-by: Alexey Brodkin > You can get the bulky one directly from the kernel source directory, and > there is definitely some value in having stripped ELF binaries as well > for devices that can load them. Well indeed in kernel's source directory we have an unstripped elf. But what happens at least in case of ARC we build only one kernel's elf and then as a post-built step we patch in .dtb for all boards we build OWRT. In other words in "bin/arc770-uClibc" folder I have: 1) openwrt-arc770-generic-axs101-initramfs.elf 2) openwrt-arc770-generic-nsim_700-initramfs.elf Both are stripped but work as they are on the corresponding boards. In "build_dir/target-arc_arc700_uClibc-1.0.9/linux-arc770_generic/linux-4.4.7/" I have perfectly unstripped vmlinux but it won't work on either board because of missing device tree blob. That means if one wants to get image for a board X with debug symbols he or she will need to do manual patching in of .dtb. Which is not the most convenient thing ever. -Alexey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] [ubox] syslog: use realloc to change log buffer size
On 18/05/16 10:45, Dan Bugnar wrote: + newest = (_log + (newest - log)); newest->size = 0; - oldest = log = _log; + memset(newest, 0, size - log_size); + oldest = (_log + (oldest - log)); + log = _log; log_end = ((void*) log) + size; Reallocating a circular buffer is non-trival. I'm concerned it doesn't cover all combinations of: (larger size OR smaller size) AND (newest > oldest OR oldest > newest) Also is there a need for locking during the log_buffer_reinit()? Conor ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] include/kernel: Do not strip kernel's Elf
On 2016-05-16 16:42, Alexey Brodkin wrote: > If an image gets built as an Elf there's a chance > it will be used by developers for debugging purposes. > In that case it's very helpful to keep debugging info > in that image. > > I would think that most OWRT-powered devices in production > will use some form of binary image for booting so Elf > flavours could be left a bit bulkier with more debug info > inside. > > Signed-off-by: Alexey Brodkin You can get the bulky one directly from the kernel source directory, and there is definitely some value in having stripped ELF binaries as well for devices that can load them. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] libubox, procd: init process hangs
On 2016-05-18 14:00, Mats Karrman wrote: > > > On 2016-05-18 13:01, Felix Fietkau wrote: >> On 2016-05-18 11:38, Mats Karrman wrote: >>> >>> On 2016-05-17 17:31, Mats Karrman wrote: On 2016-05-17 13:29, Felix Fietkau wrote: > I just took a look at the code and uloop's processing of signals looked > a bit racy to me. I've pushed a commit that makes it use signalfd if > available. I also found that waitpid wasn't being retried on signal > interrupt, so I added an extra check there. The changes are in libubox > git, but not in OpenWrt/LEDE yet. > Please test if this fixes your issue. > > Thanks, > > - Felix Tried that but no immediate success, but it might have provided some additional clues. Now the boot hangs early on *every* boot but after logging in I found something different in the ps list. There is a Broadcom utility (smd) that is called from one of the start scripts (S10environment). It's purpose is to set scheduling priority and cpu affinity for some of the Broadcom proprietary processes, The smd program handles fork rather ugly. The parent only loops until it receives SIGCHLD and then exits without any wait. With the modified libubox I get a zombie smd child and sleeping smd parent and S11environment (no other zombie). Not sure exactly how this happened but I got to think about something written in the wait man page: """ If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies. """ Is this wait really (unconditionally) implemented in procd or could that be what I accomplished with the "forced timeout" patch? I fixed the ugly fork and got the system to boot once. Then tried the original libubox with the fixed smd program but this was not enough to get things working (25 reboots to hang). Now I'm running reboot tests with your new libubox and fixed smd... >>> More than 250 reboots without problem :) >>> >>> Clearly the smd program is broken, but still it doesn't feel good that it >>> manages to hang the init process. Considering that timing is involved >>> it's difficult to make any certain conclusions but it seems like having >>> uloop epoll_wait to time out occasionally isn't such a bad idea? >> I agree, that definitely needs fixing. What kernel are you using? > It's the 3.4.11-rt19 from the Broadcom SDK v4.16, so very old... > > Now I also noticed, with your libubox fixes (and my fixed smd) I still get > some zombies, even though the system seems to boot OK all the way > (the corresponding services being defunct though). > With my epoll_wait timeout fix on the original libubox, this does not > happen. Can you try backporting this to your kernel? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=128dd1759d96ad36c379240f8b9463e8acfd37a1 - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] libubox, procd: init process hangs
On 2016-05-18 13:01, Felix Fietkau wrote: On 2016-05-18 11:38, Mats Karrman wrote: On 2016-05-17 17:31, Mats Karrman wrote: On 2016-05-17 13:29, Felix Fietkau wrote: I just took a look at the code and uloop's processing of signals looked a bit racy to me. I've pushed a commit that makes it use signalfd if available. I also found that waitpid wasn't being retried on signal interrupt, so I added an extra check there. The changes are in libubox git, but not in OpenWrt/LEDE yet. Please test if this fixes your issue. Thanks, - Felix Tried that but no immediate success, but it might have provided some additional clues. Now the boot hangs early on *every* boot but after logging in I found something different in the ps list. There is a Broadcom utility (smd) that is called from one of the start scripts (S10environment). It's purpose is to set scheduling priority and cpu affinity for some of the Broadcom proprietary processes, The smd program handles fork rather ugly. The parent only loops until it receives SIGCHLD and then exits without any wait. With the modified libubox I get a zombie smd child and sleeping smd parent and S11environment (no other zombie). Not sure exactly how this happened but I got to think about something written in the wait man page: """ If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies. """ Is this wait really (unconditionally) implemented in procd or could that be what I accomplished with the "forced timeout" patch? I fixed the ugly fork and got the system to boot once. Then tried the original libubox with the fixed smd program but this was not enough to get things working (25 reboots to hang). Now I'm running reboot tests with your new libubox and fixed smd... More than 250 reboots without problem :) Clearly the smd program is broken, but still it doesn't feel good that it manages to hang the init process. Considering that timing is involved it's difficult to make any certain conclusions but it seems like having uloop epoll_wait to time out occasionally isn't such a bad idea? I agree, that definitely needs fixing. What kernel are you using? It's the 3.4.11-rt19 from the Broadcom SDK v4.16, so very old... Now I also noticed, with your libubox fixes (and my fixed smd) I still get some zombies, even though the system seems to boot OK all the way (the corresponding services being defunct though). With my epoll_wait timeout fix on the original libubox, this does not happen. BR // Mats ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements
On 18/05/2016 13:35, Daniel Curran-Dickinson wrote: > On 16-05-18 07:31 AM, Conor O'Gorman wrote: >> On 18/05/16 12:21, Jo-Philipp Wich wrote: >>> On 05/18/2016 12:12 PM,l...@daniel.thecshore.com wrote: > Hi John, > > I haven't tested these changes yet, >> Testing would be good before next submission. > > The whole point of the [RFC] is that it's a request for comments, prior > to the full submission process. > > Regards, > > Daniel > thanks !, please send a full series without RFC once you tested this on device. John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Please enable digest mode for lede-dev
On 18.5.2016 14:02, Jo-Philipp Wich wrote: Hi Hannu, Please allow users to select to receive lede-dev messages in digests. Done, please let me know whether it is working. ~ Jo Thanks, it works great. I enabled digest mode and the first digest message just arrived :-( And the MIME digest mode enables picking a single message from the digest message and answering to that, decreasing the risk that Arjen mentioned. (At least Thunderbird supports these list message digests nicely.) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements
On 16-05-18 07:31 AM, Conor O'Gorman wrote: > On 18/05/16 12:21, Jo-Philipp Wich wrote: >> On 05/18/2016 12:12 PM,l...@daniel.thecshore.com wrote: >>> >Hi John, >>> > >>> >I haven't tested these changes yet, > Testing would be good before next submission. The whole point of the [RFC] is that it's a request for comments, prior to the full submission process. Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements
On 16-05-18 07:31 AM, Conor O'Gorman wrote: > On 18/05/16 12:21, Jo-Philipp Wich wrote: >> On 05/18/2016 12:12 PM,l...@daniel.thecshore.com wrote: >>> >Hi John, >>> > >>> >I haven't tested these changes yet, > Testing would be good before next submission. My goal was actually to make sure that I was headed in the right direction before doing builds and flashing images and generally spending time that would be wasted if it wasn't what was wanted. Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements
On 18/05/16 12:21, Jo-Philipp Wich wrote: On 05/18/2016 12:12 PM,l...@daniel.thecshore.com wrote: >Hi John, > >I haven't tested these changes yet, Testing would be good before next submission. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/4] v2: block.c: Add support for checking vfat filesystems
From: Daniel Dickinson
v2: Fix mixup of dosfsck checking ext* and e2fsck checking vfat.
vfat is a common filesystem which users may want to mount on an
OpenWrt/LEDE device, so support peforming filesystem checks
before mount for vfat.
Signed-off-by: Daniel Dickinson
---
block.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/block.c b/block.c
index 71ffd0b..5a584cb 100644
--- a/block.c
+++ b/block.c
@@ -628,24 +628,30 @@ static void check_filesystem(struct blkid_struct_probe
*pr)
pid_t pid;
struct stat statbuf;
const char *e2fsck = "/usr/sbin/e2fsck";
+ const char *dosfsck = "/sbin/dosfsck";
+ const char *ckfs;
/* UBIFS does not need stuff like fsck */
if (!strncmp(pr->id->name, "ubifs", 5))
return;
- if (strncmp(pr->id->name, "ext", 3)) {
+ if (!strncmp(pr->id->name, "vfat", 4)) {
+ ckfs = dosfsck;
+ } else if (!strncmp(pr->id->name, "ext", 3)) {
+ ckfs = e2fsck;
+ } else {
ULOG_ERR("check_filesystem: %s is not supported\n",
pr->id->name);
return;
}
- if (stat(e2fsck, &statbuf) < 0) {
+ if (stat(ckfs, &statbuf) < 0) {
ULOG_ERR("check_filesystem: %s not found\n", e2fsck);
return;
}
pid = fork();
if (!pid) {
- execl(e2fsck, e2fsck, "-p", pr->dev, NULL);
+ execl(ckfs, ckfs, "-p", pr->dev, NULL);
exit(-1);
} else if (pid > 0) {
int status;
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Please enable digest mode for lede-dev
On Wed, 2016-05-18 at 12:29 +0200, Arjen de Korte wrote: > Is it possible to prevent people from replying to these digest > messages? I'm seeing this happen a lot on other mailinglist I follow > and it makes conversation mode almost useless. You can filter on 'lede-dev digest' in the subject. I used to do this but mostly gave up on it and just turned digests off for all the lists. There's no good reason for it other than "I can't be bothered to do email properly". -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems
Hi,
>>> +if (!strncmp(pr->id->name, "vfat", 4)) {
"If fs name starts with vfat ..."
>>> +ckfs = e2fsck;
"... then use the ext4 checker".
>>> +} else if (!strncmp(pr->id->name, "ext", 3)) {
"... else if fs name starts with ext ..."
>>> +ckfs = dosfsck;
"... then use the dosfs checker".
>> Is this the wrong way round?
>
> Do you mean you mean you think ext should be tested first?
That certainly looks swapped to me as well.
~ Jo
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements
Hi Daniel, ACK from me once the fs checker swap is fixed. ~ Jo On 05/18/2016 12:12 PM, l...@daniel.thecshore.com wrote: > Hi John, > > I haven't tested these changes yet, but is this what you were looking for > in terms of changes to the patches previously as part of the PRs you > commented on? > > [PATCH 1/4] [RFC] fstools: block.c: Make static string a const char * instead > char * > [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems > [PATCH 3/4] [RFC] fstools: block.c: Use instead of defining > mount flags > [PATCH 4/4] [RFC] fstools: block.c: Add ability to mount with ACL and XATTR > support > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems
On 16-05-18 07:17 AM, Arjen de Korte wrote: > Citeren Daniel Dickinson : > > > I guess "vfat" should be checked with dosfsck and "ext" with e2fsck. > Ah, the old you see what you expect to see psychology thing - I missed that. Regards, Daniel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Please enable digest mode for lede-dev
On 18.05.2016 12:29, Arjen de Korte wrote: Citeren Hannu Nyman : Please allow users to select to receive lede-dev messages in digests. The lede-dev mailing list is already rather high volume list and if the possible PR discussion messages from Github is also piped here, the amount of messages might be rather high. Devs have disabled the "digest mode" in the mailing list's settings and thus users can't select to receive messagess in digest format. Please toggle the switch and allow users to receive messages in digest format if they so wish. Is it possible to prevent people from replying to these digest messages? I'm seeing this happen a lot on other mailinglist I follow and it makes conversation mode almost useless. I'm also afraid, this might happen. I've seen this also on other lists before. I think almost any mail account should have capabilites to filter emails to a separate folder. If people answer on these digest emails, the information where these emails belong is totally lost. I don't want to be offensive, but if one did not even invested time to setup a separate folder, sometimes even the digest subject stays. Especially when you are on a busy list and do not want to follow everything it's more easy to get this goal. I attached a file how tree view looks, just to show the advantages you can get from it. When everything is in a sepearate folder. This gets impossible when people answer to digests, thats my two cents why I think it is a god thing to disallow digests, if there is active discussion on a list. Regards Tobias ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems
Citeren Daniel Dickinson :
On 16-05-18 07:05 AM, Conor O'Gorman wrote:
On 18/05/16 11:12, l...@daniel.thecshore.com wrote:
+if (!strncmp(pr->id->name, "vfat", 4)) {
+ckfs = e2fsck;
+} else if (!strncmp(pr->id->name, "ext", 3)) {
+ckfs = dosfsck;
Is this the wrong way round?
Do you mean you mean you think ext should be tested first?
ckfs = x is obvious correction because we're setting the ckfs to the
command to do the filesystem check.
Otherwise I'm not sure what you're asking...
Perhaps your problem is with the C idiom (!strncmp is correct because
strncmp returns 0 on a match (which == false for the if)).
I have no other guesses as to what you're getting at.
I guess "vfat" should be checked with dosfsck and "ext" with e2fsck.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems
On 16-05-18 07:05 AM, Conor O'Gorman wrote:
> On 18/05/16 11:12, l...@daniel.thecshore.com wrote:
>> +if (!strncmp(pr->id->name, "vfat", 4)) {
>> +ckfs = e2fsck;
>> +} else if (!strncmp(pr->id->name, "ext", 3)) {
>> +ckfs = dosfsck;
> Is this the wrong way round?
Do you mean you mean you think ext should be tested first?
ckfs = x is obvious correction because we're setting the ckfs to the
command to do the filesystem check.
Otherwise I'm not sure what you're asking...
Perhaps your problem is with the C idiom (!strncmp is correct because
strncmp returns 0 on a match (which == false for the if)).
I have no other guesses as to what you're getting at.
Regards,
Daniel
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems
On 18/05/16 11:12, l...@daniel.thecshore.com wrote:
+ if (!strncmp(pr->id->name, "vfat", 4)) {
+ ckfs = e2fsck;
+ } else if (!strncmp(pr->id->name, "ext", 3)) {
+ ckfs = dosfsck;
Is this the wrong way round?
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Please enable digest mode for lede-dev
Hi Hannu, > Please allow users to select to receive lede-dev messages in digests. Done, please let me know whether it is working. ~ Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] libubox, procd: init process hangs
On 2016-05-18 11:38, Mats Karrman wrote: > > > On 2016-05-17 17:31, Mats Karrman wrote: >> >> On 2016-05-17 13:29, Felix Fietkau wrote: >>> I just took a look at the code and uloop's processing of signals looked >>> a bit racy to me. I've pushed a commit that makes it use signalfd if >>> available. I also found that waitpid wasn't being retried on signal >>> interrupt, so I added an extra check there. The changes are in libubox >>> git, but not in OpenWrt/LEDE yet. >>> Please test if this fixes your issue. >>> >>> Thanks, >>> >>> - Felix >> Tried that but no immediate success, but it might have provided >> some additional clues. Now the boot hangs early on *every* boot >> but after logging in I found something different in the ps list. >> There is a Broadcom utility (smd) that is called from one of the >> start scripts (S10environment). It's purpose is to set scheduling >> priority and cpu affinity for some of the Broadcom proprietary >> processes, The smd program handles fork rather ugly. The >> parent only loops until it receives SIGCHLD and then exits without >> any wait. With the modified libubox I get a zombie smd child and >> sleeping smd parent and S11environment (no other zombie). >> >> Not sure exactly how this happened but I got to think about >> something written in the wait man page: >> >> """ >> If a parent process terminates, then its "zombie" children (if any) >> are adopted by init(8), which automatically performs a wait to >> remove the zombies. >> """ >> >> Is this wait really (unconditionally) implemented in procd or could >> that be what I accomplished with the "forced timeout" patch? >> >> I fixed the ugly fork and got the system to boot once. >> Then tried the original libubox with the fixed smd program but >> this was not enough to get things working (25 reboots to hang). >> >> Now I'm running reboot tests with your new libubox and fixed smd... > More than 250 reboots without problem :) > > Clearly the smd program is broken, but still it doesn't feel good that it > manages to hang the init process. Considering that timing is involved > it's difficult to make any certain conclusions but it seems like having > uloop epoll_wait to time out occasionally isn't such a bad idea? I agree, that definitely needs fixing. What kernel are you using? - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC] uhttpd: [PATCH 2/2] handlers: Add more sophisticated prefix/path matching heuristic
From: Daniel Dickinson
We prefer either a path match (e.g. interpreter extension match)
then the longest matching prefix (e.g. /cgi-bin/luci handler is used
except if a prefix matches a virtual url before the path matching
logic is hit.
Note that we now allow a handler to have both check_url and check_path
to support this.
Also note that if a handler has both a path match and a prefix match
AND one of its prefixes is the most specific match for this url,
then before path_lookup this code will return NULL (no match)
to ensure that the path match has a chance to override the prefix.
Signed-off-by: Daniel Dickinson
---
NOTE: This is basically untested and is provided to solicit comments
for something for which there may be no interest before spending
more time on it.
cgi.c| 11 ++-
file.c | 60 +++-
lua.c| 6 --
proxy.c | 6 +++---
ubus.c | 6 --
uhttpd.h | 2 +-
6 files changed, 73 insertions(+), 18 deletions(-)
diff --git a/cgi.c b/cgi.c
index dc302a9..b274e4c 100644
--- a/cgi.c
+++ b/cgi.c
@@ -84,6 +84,14 @@ static void cgi_handle_request(struct client *cl, char *url,
struct path_info *p
return;
}
+static const char *check_cgi_url(const char *url)
+{
+ if (uh_path_match(conf.cgi_docroot_path, url))
+ return conf.cgi_docroot_path;
+
+ return NULL;
+}
+
static bool check_cgi_path(struct path_info *pi, const char *url)
{
struct interpreter *ip;
@@ -104,11 +112,12 @@ static bool check_cgi_path(struct path_info *pi, const
char *url)
}
pi->ip = NULL;
- return uh_path_match(conf.cgi_docroot_path, pi->phys);
+ return false;
}
struct dispatch_handler cgi_dispatch = {
.script = true,
.check_path = check_cgi_path,
+ .check_url = check_cgi_url,
.handle_request = cgi_handle_request,
};
diff --git a/file.c b/file.c
index 12aa130..6d7ff0c 100644
--- a/file.c
+++ b/file.c
@@ -38,6 +38,7 @@
static LIST_HEAD(index_files);
static LIST_HEAD(dispatch_handlers);
static LIST_HEAD(pending_requests);
+static LIST_HEAD(matches);
static int n_requests;
struct deferred_request {
@@ -654,27 +655,68 @@ void uh_dispatch_add(struct dispatch_handler *d)
}
static struct dispatch_handler *
+dispatch_check_match(struct dispatch_handler *d, const char *url, size_t
*max_len) {
+ const char *matching_path;
+ size_t len;
+
+ if (d->check_url)
+ if ((matching_path = d->check_url(url))) {
+ len = strlen(matching_path);
+ if (len > *max_len) {
+ *max_len = len;
+ return d;
+ }
+ }
+
+ return NULL;
+}
+
+/* We prefer either a path match (e.g. interpreter extension match)
+ * then the longest matching prefix (e.g. /cgi-bin/luci handler is used
+ * except if a prefix matches a virtual url before the path matching
+ * logic is hit.
+ * Note that we now allow a handler to have both check_url and check_path
+ * to support this.
+ * Also note that if a handler has both a path match and a prefix match
+ * AND one of its prefixes is the most specific match for this url,
+ * then before path_lookup this code will return NULL (no match)
+ * to ensure that the path match has a chance to override the prefix.
+ */
+static struct dispatch_handler *
dispatch_find(const char *url, struct path_info *pi)
{
struct dispatch_handler *d;
+ struct dispatch_handler *m = NULL;
+ size_t max_len = 0;
list_for_each_entry(d, &dispatch_handlers, list) {
if (pi) {
- if (d->check_url)
- continue;
-
+ /* Prefer a path (e.g. interpreter extension)
+* match to a prefix match
+ */
if (d->check_path(pi, url))
return d;
- } else {
- if (d->check_path)
- continue;
- if (d->check_url(url))
- return d;
+ if (dispatch_check_match(d, url, &max_len))
+ m = d;
+ } else {
+ /* for handlers with both prefixes and path matches we
+* want the path match to actually occur which means
+* that we can't check prefixes until after path_lookup
+* is done and we have the final path.
+*/
+
+ if (dispatch_check_match(d, url, &max_len)) {
+ if (d->check_path) {
+ m = NULL;
+ } else {
+ m = d;
+ }
+
[LEDE-DEV] [RFC] uhttpd: [PATCH 1/2] modules: Add proxy module
From: Daniel Dickinson
A first attempt at simple HTTP proxy support (to allow
URL beginning with /prefix to really be access to some
other server; this is potenitally useful with some
web applications, or if you want to have a single
entry point to multiple servers (and aren't serving
huge traffic).
Signed-off-by: Daniel Dickinson
---
NOTE: This is basically untested and is provided to get comments
before proceeding with something which may be of no interest.
CMakeLists.txt | 11 +-
client.c | 90 +++--
listen.c | 6 +-
main.c | 41 +-
proc.c | 38 ++
proxy.c| 406 +
uhttpd.h | 53
utils.c| 52 ++--
8 files changed, 667 insertions(+), 30 deletions(-)
create mode 100644 proxy.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8514351..3bf39db 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -10,6 +10,7 @@ ADD_DEFINITIONS(-D_FILE_OFFSET_BITS=64 -Os -Wall -Werror
-Wmissing-declarations
OPTION(TLS_SUPPORT "TLS support" ON)
OPTION(LUA_SUPPORT "Lua support" ON)
OPTION(UBUS_SUPPORT "ubus support" ON)
+OPTION(PROXY_SUPPORT "proxy support" ON)
IF(APPLE)
INCLUDE_DIRECTORIES(/opt/local/include)
@@ -32,9 +33,7 @@ IF(HAVE_SHADOW)
ADD_DEFINITIONS(-DHAVE_SHADOW)
ENDIF()
-ADD_EXECUTABLE(uhttpd ${SOURCES})
FIND_LIBRARY(libjson NAMES json-c json)
-TARGET_LINK_LIBRARIES(uhttpd ubox dl json_script blobmsg_json ${libjson}
${LIBS})
SET(PLUGINS "")
IF(LUA_SUPPORT)
@@ -73,6 +72,14 @@ IF(UBUS_SUPPORT)
TARGET_LINK_LIBRARIES(uhttpd_ubus ubus ubox blobmsg_json ${libjson})
ENDIF()
+IF(PROXY_SUPPORT)
+ SET(SOURCES ${SOURCES} proxy.c)
+ ADD_DEFINITIONS(-DHAVE_PROXY)
+ENDIF()
+
+ADD_EXECUTABLE(uhttpd ${SOURCES})
+TARGET_LINK_LIBRARIES(uhttpd ubox dl json_script blobmsg_json ${libjson}
${LIBS})
+
IF(PLUGINS)
SET_TARGET_PROPERTIES(${PLUGINS} PROPERTIES
PREFIX ""
diff --git a/client.c b/client.c
index 73e0e49..4643a56 100644
--- a/client.c
+++ b/client.c
@@ -24,9 +24,11 @@
#include "tls.h"
static LIST_HEAD(clients);
-static bool client_done = false;
+bool client_done = false;
int n_clients = 0;
+int n_connections = 0;
+
struct config conf = {};
const char * const http_versions[] = {
@@ -40,6 +42,9 @@ const char * const http_methods[] = {
[UH_HTTP_MSG_POST] = "POST",
[UH_HTTP_MSG_HEAD] = "HEAD",
[UH_HTTP_MSG_OPTIONS] = "OPTIONS",
+ [UH_HTTP_MSG_DELETE] = "DELETE",
+ [UH_HTTP_MSG_PUT] = "PUT",
+ [UH_HTTP_MSG_CONNECT] = "CONNECT",
};
void uh_http_header(struct client *cl, int code, const char *summary)
@@ -73,7 +78,7 @@ static void uh_connection_close(struct client *cl)
ustream_state_change(cl->us);
}
-static void uh_dispatch_done(struct client *cl)
+void uh_dispatch_done(struct client *cl)
{
if (cl->dispatch.free)
cl->dispatch.free(cl);
@@ -104,7 +109,7 @@ static void uh_keepalive_poll_cb(struct uloop_timeout
*timeout)
cl->us->notify_read(cl->us, 0);
}
-static void uh_poll_connection(struct client *cl)
+void uh_poll_connection(struct client *cl)
{
cl->timeout.cb = uh_keepalive_poll_cb;
uloop_timeout_set(&cl->timeout, 1);
@@ -160,6 +165,49 @@ static int find_idx(const char * const *list, int max,
const char *str)
return -1;
}
+#ifdef HAVE_PROXY
+static int client_parse_response(struct client *cl, char *data)
+{
+ struct client *proxycl = cl->proxycl;
+
+ if (!proxycl)
+ return CLIENT_STATE_DONE;
+
+ struct http_request *req = &cl->request;
+ char *code, *msg, *version;
+ int h_version;
+
+ version = strtok(data, " ");
+ code = strtok(NULL, " ");
+ msg = strtok(NULL, " ");
+ if (!code || !msg || !version)
+ goto error;
+
+ memset(&cl->request, 0, sizeof(cl->request));
+ h_version = find_idx(http_versions, ARRAY_SIZE(http_versions), version);
+ if (h_version < 0) {
+ req->version = UH_HTTP_VER_1_0;
+ return CLIENT_STATE_DONE;
+ }
+
+ req->method = proxycl->request.method;
+ req->version = h_version;
+ if (req->version < UH_HTTP_VER_1_1 || req->method == UH_HTTP_MSG_POST ||
+ !conf.http_keepalive)
+ req->connection_close = true;
+ req->code = atoi(code);
+ req->msg = strdup(msg);
+ if (req->code <= 0)
+ goto error;
+
+ return CLIENT_STATE_HEADER;
+
+ error:
+ uh_client_error(cl->proxycl, 502, "Bad Gateway", "Invalid
response from target\n");
+ return CLIENT_STATE_DONE;
+}
+#endif
+
static int client_parse_request(struct client *cl, char *data)
{
struct http_request *req = &cl->request;
@@ -206,10 +254,30 @@ static bool client_init_cb(struct client *cl, char *buf,
int len)
*newline = 0;
blob_buf_init(&cl->hdr, 0);
+
Re: [LEDE-DEV] Please enable digest mode for lede-dev
Citeren Hannu Nyman : Please allow users to select to receive lede-dev messages in digests. The lede-dev mailing list is already rather high volume list and if the possible PR discussion messages from Github is also piped here, the amount of messages might be rather high. Devs have disabled the "digest mode" in the mailing list's settings and thus users can't select to receive messagess in digest format. Please toggle the switch and allow users to receive messages in digest format if they so wish. Is it possible to prevent people from replying to these digest messages? I'm seeing this happen a lot on other mailinglist I follow and it makes conversation mode almost useless. Ps. the disabled digest mode might be one reason why there is so much actual conversation. Each message arrives separately so it is easy to answer. So it might be best if the digest mode is allowed but the default is still individual messages. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Please enable digest mode for lede-dev
Please allow users to select to receive lede-dev messages in digests. The lede-dev mailing list is already rather high volume list and if the possible PR discussion messages from Github is also piped here, the amount of messages might be rather high. Devs have disabled the "digest mode" in the mailing list's settings and thus users can't select to receive messagess in digest format. Please toggle the switch and allow users to receive messages in digest format if they so wish. Ps. the disabled digest mode might be one reason why there is so much actual conversation. Each message arrives separately so it is easy to answer. So it might be best if the digest mode is allowed but the default is still individual messages. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 0/4] [RFC] fstools: block.c: Various enhancements
Hi John, I haven't tested these changes yet, but is this what you were looking for in terms of changes to the patches previously as part of the PRs you commented on? [PATCH 1/4] [RFC] fstools: block.c: Make static string a const char * instead char * [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems [PATCH 3/4] [RFC] fstools: block.c: Use instead of defining mount flags [PATCH 4/4] [RFC] fstools: block.c: Add ability to mount with ACL and XATTR support ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 4/4] [RFC] fstools: block.c: Add ability to mount with ACL and XATTR support
From: Daniel Dickinson
Some users will want to use OpenWrt/LEDE devices as NAS
devices and have full POSIX ACL and user_xattr support
(along with other possible use cases), therefore add
support to mount with POSIX ACLs and/or user XATTR
support.
Signed-off-by: Daniel Dickinson
---
block.c | 4
1 file changed, 4 insertions(+)
diff --git a/block.c b/block.c
index d30b1f6..1da0a12 100644
--- a/block.c
+++ b/block.c
@@ -170,6 +170,10 @@ static const struct mount_flag mount_flags[] = {
{ "relatime", MS_RELATIME },
{ "norelatime", ~MS_RELATIME},
{ "strictatime",MS_STRICTATIME },
+ { "acl",MS_ACL },
+ { "noacl", ~MS_ACL },
+ { "nouser_xattr", MS_NOUSER },
+ { "user_xattr", ~MS_NOUSER },
};
static char *blobmsg_get_strdup(struct blob_attr *attr)
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/4] [RFC] fstools: block.c: Make static string a const char * instead char *
From: Daniel Dickinson
There is no reason for e2fsck string to be altered, and the
only places where is used take const char * as parameters
so make e2fsck a const char *.
Signed-off-by: Daniel Dickinson
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
index ef58665..71ffd0b 100644
--- a/block.c
+++ b/block.c
@@ -627,7 +627,7 @@ static void check_filesystem(struct blkid_struct_probe *pr)
{
pid_t pid;
struct stat statbuf;
- char *e2fsck = "/usr/sbin/e2fsck";
+ const char *e2fsck = "/usr/sbin/e2fsck";
/* UBIFS does not need stuff like fsck */
if (!strncmp(pr->id->name, "ubifs", 5))
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/4] [RFC] fstools: block.c: Add support for checking vfat filesystems
From: Daniel Dickinson
vfat is a common filesystem which users may want to mount on an
OpenWrt/LEDE device, so support peforming filesystem checks
before mount for vfat.
Signed-off-by: Daniel Dickinson
---
block.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/block.c b/block.c
index 71ffd0b..c2adf3c 100644
--- a/block.c
+++ b/block.c
@@ -628,24 +628,30 @@ static void check_filesystem(struct blkid_struct_probe
*pr)
pid_t pid;
struct stat statbuf;
const char *e2fsck = "/usr/sbin/e2fsck";
+ const char *dosfsck = "/sbin/dosfsck";
+ const char *ckfs;
/* UBIFS does not need stuff like fsck */
if (!strncmp(pr->id->name, "ubifs", 5))
return;
- if (strncmp(pr->id->name, "ext", 3)) {
+ if (!strncmp(pr->id->name, "vfat", 4)) {
+ ckfs = e2fsck;
+ } else if (!strncmp(pr->id->name, "ext", 3)) {
+ ckfs = dosfsck;
+ } else {
ULOG_ERR("check_filesystem: %s is not supported\n",
pr->id->name);
return;
}
- if (stat(e2fsck, &statbuf) < 0) {
+ if (stat(ckfs, &statbuf) < 0) {
ULOG_ERR("check_filesystem: %s not found\n", e2fsck);
return;
}
pid = fork();
if (!pid) {
- execl(e2fsck, e2fsck, "-p", pr->dev, NULL);
+ execl(ckfs, ckfs, "-p", pr->dev, NULL);
exit(-1);
} else if (pid > 0) {
int status;
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/4] [RFC] fstools: block.c: Use instead of defining mount flags ourselves
From: Daniel Dickinson
Let's use the cannonical source of mount flags instead of
defining the flags ourselves.
Signed-off-by: Daniel Dickinson
---
block.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index ef58665..d30b1f6 100644
--- a/block.c
+++ b/block.c
@@ -29,6 +29,8 @@
#include
#include
+#include
+
#include
#include
@@ -147,18 +149,6 @@ struct mount_flag {
int32_t flag;
};
-#ifndef MS_DIRSYNC
-# define MS_DIRSYNC (1 << 7)
-#endif
-
-#ifndef MS_RELATIME
-# define MS_RELATIME (1 << 21)
-#endif
-
-#ifndef MS_STRICTATIME
-# define MS_STRICTATIME (1 << 24)
-#endif
-
static const struct mount_flag mount_flags[] = {
{ "sync", MS_SYNCHRONOUS },
{ "async", ~MS_SYNCHRONOUS },
--
1.9.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method
From: Dan Bugnar
Add ubus method to set the buffer size.
Signed-off-by: Dan Bugnar
---
log/logd.c | 28 +++-
log/syslog.c | 8 +---
log/syslog.h | 2 +-
3 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/log/logd.c b/log/logd.c
index 27d3cac..93ca0e8 100644
--- a/log/logd.c
+++ b/log/logd.c
@@ -26,11 +26,16 @@
#include "syslog.h"
+#define LOG_DEFAULT_SIZE 16 * 1024
+
int debug = 0;
static struct blob_buf b;
static struct ubus_auto_conn conn;
static LIST_HEAD(clients);
+static const struct blobmsg_policy reload_policy =
+ { .name = "log_buffer_size", .type = BLOBMSG_TYPE_INT32 };
+
static const struct blobmsg_policy read_policy =
{ .name = "lines", .type = BLOBMSG_TYPE_INT32 };
@@ -124,9 +129,29 @@ write_log(struct ubus_context *ctx, struct ubus_object
*obj,
return 0;
}
+static int
+reload_log(struct ubus_context *ctx, struct ubus_object *obj,
+ struct ubus_request_data *req, const char *method,
+ struct blob_attr *msg)
+{
+ struct blob_attr *tb;
+ int size = 0;
+
+ if (msg) {
+ blobmsg_parse(&reload_policy, 1, &tb, blob_data(msg),
blob_len(msg));
+ if (tb) {
+ size = blobmsg_get_u32(tb);
+ log_buffer_reinit(size < 1 ? LOG_DEFAULT_SIZE : size *
1024);
+ }
+ }
+
+ return 0;
+}
+
static const struct ubus_method log_methods[] = {
{ .name = "read", .handler = read_log, .policy = &read_policy,
.n_policy = 1 },
{ .name = "write", .handler = write_log, .policy = &write_policy,
.n_policy = 1 },
+ { .name = "reload", .handler = reload_log, .policy = &reload_policy,
.n_policy = 1 },
};
static struct ubus_object_type log_object_type =
@@ -191,7 +216,8 @@ main(int argc, char **argv)
log_size *= 1024;
uloop_init();
- log_init(log_size);
+ log_init();
+ log_buffer_reinit(log_size);
conn.cb = ubus_connect_handler;
ubus_auto_connect(&conn);
uloop_run();
diff --git a/log/syslog.c b/log/syslog.c
index d6cb868..683eeb8 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -270,16 +270,10 @@ log_buffer_reinit(int size)
}
void
-log_init(int _log_size)
+log_init()
{
regcomp(&pat_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
regcomp(&pat_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
-
- if (log_buffer_reinit(_log_size)) {
- fprintf(stderr, "Failed to allocate log memory\n");
- exit(-1);
- }
-
syslog_open();
klog_open();
openlog("sysinit", LOG_CONS, LOG_DAEMON);
diff --git a/log/syslog.h b/log/syslog.h
index ed5a41b..fe815b9 100644
--- a/log/syslog.h
+++ b/log/syslog.h
@@ -30,7 +30,7 @@ struct log_head {
char data[];
};
-void log_init(int log_size);
+void log_init();
void log_shutdown(void);
typedef void (*log_list_cb)(struct log_head *h);
--
2.8.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] [ubox] syslog: use realloc to change log buffer size
From: Dan Bugnar
Change the log buffer size and copy the messages.
Signed-off-by: Dan Bugnar
---
log/syslog.c | 37 +++--
log/syslog.h | 2 +-
2 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/log/syslog.c b/log/syslog.c
index e8b6774..d6cb868 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -42,7 +42,7 @@
#define PAD(x) (x % 4) ? (((x) - (x % 4)) + 4) : (x)
static char *log_dev = LOG_DEFAULT_SOCKET;
-static int log_size = LOG_DEFAULT_SIZE;
+static int log_size = 0;
static struct log_head *log, *log_end, *oldest, *newest;
static int current_id = 0;
static regex_t pat_prio;
@@ -237,34 +237,30 @@ log_list(int count, struct log_head *h)
}
int
-log_buffer_init(int size)
+log_buffer_reinit(int size)
{
- struct log_head *_log = malloc(size);
+ if (size <= 0)
+ size = LOG_DEFAULT_SIZE;
+ if (log_size == size)
+ return 0;
+
+ struct log_head *_log = realloc(log, size);
if (!_log) {
+ oldest = newest = log = NULL;
fprintf(stderr, "Failed to initialize log buffer with size
%d\n", log_size);
return -1;
}
- memset(_log, 0, size);
-
if (log && ((log_size + sizeof(struct log_head)) < size)) {
- struct log_head *start = _log;
- struct log_head *end = ((void*) _log) + size;
- struct log_head *l;
-
- l = log_list(0, NULL);
- while ((start < end) && l && l->size) {
- memcpy(start, l, PAD(sizeof(struct log_head) +
l->size));
- start = (struct log_head *) &l->data[PAD(l->size)];
- l = log_list(0, l);
- }
- free(log);
- newest = start;
+ newest = (_log + (newest - log));
newest->size = 0;
- oldest = log = _log;
+ memset(newest, 0, size - log_size);
+ oldest = (_log + (oldest - log));
+ log = _log;
log_end = ((void*) log) + size;
} else {
+ memset(_log, 0, size);
oldest = newest = log = _log;
log_end = ((void*) log) + size;
}
@@ -276,13 +272,10 @@ log_buffer_init(int size)
void
log_init(int _log_size)
{
- if (_log_size > 0)
- log_size = _log_size;
-
regcomp(&pat_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
regcomp(&pat_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
- if (log_buffer_init(log_size)) {
+ if (log_buffer_reinit(_log_size)) {
fprintf(stderr, "Failed to allocate log memory\n");
exit(-1);
}
diff --git a/log/syslog.h b/log/syslog.h
index 81a039f..ed5a41b 100644
--- a/log/syslog.h
+++ b/log/syslog.h
@@ -35,7 +35,7 @@ void log_shutdown(void);
typedef void (*log_list_cb)(struct log_head *h);
struct log_head* log_list(int count, struct log_head *h);
-int log_buffer_init(int size);
+int log_buffer_reinit(int size);
void log_add(char *buf, int size, int source);
void ubus_notify_log(struct log_head *l);
--
2.8.1
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/16 11:10, David Lang wrote: On Wed, 18 May 2016, Ferry Huberts wrote: On 18/05/16 10:03, David Lang wrote: On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:46, Ferry Huberts wrote: already in-place in Fedora and RedHat/CentOS. You then get even stronger protection and run-time performance impact is negligible. the stuff i proposed has not runtime hit. selinux is simple to full SELinux's hit is for all intents and purposes zero as well nowadays. blown and hard to maintain. the idea would be to create a custom tailored solution for our requirements. That is why I prefer AppArmor, you don't have the interaction between different application configs that you do with SELinux, so you can focus on the specific application that you are concerned about. AppArmor is significantly less secure than SELinux. And with SELinux you don't need all the preloading stuff that was talked about, you can just declare which ports are allowed. tightly configured in expert hands, you are right. However, that's not the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll point out that if home users are familar with Linux, the odds are good that it's a flavor of Ubuntu that uses AA rather than Fedora that uses SELinux. (not worth much because the home user probably hasn't touched AA or SELinux) That should not be an argument to do one or the other. You should ask yourself how far you would want to go in securing a router. Personally, I would absolutely love a router with a tight SELinux policy since it protects me well from unsavory access from the outside. do all the compressed filesystems support the tagging needed by SELinux? what about external drives with FAT* or NTFS? FAT and NTFS do not support it AFAIK, but how is that a problem? You'd run SELinux on your internal filesystem. For the compressed filesystems: I don't know, they will probably support it if they're good citizen Linux filesystems. How do you handle the possible need to re-label your files on a read-only filesystem? Don't know, but take a look at Android, it has SELinux enabled in enforcing mode (the strongest mode). what is the difference in kernel size (and tool size) between AA and SELinux? Don't know. For clarity (and for weaseling out): I read a snip of the discussion and wanted to offer another alternative, so that the discussion could consider it. -- Ferry Huberts ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] libubox, procd: init process hangs
On 2016-05-17 17:31, Mats Karrman wrote: On 2016-05-17 13:29, Felix Fietkau wrote: I just took a look at the code and uloop's processing of signals looked a bit racy to me. I've pushed a commit that makes it use signalfd if available. I also found that waitpid wasn't being retried on signal interrupt, so I added an extra check there. The changes are in libubox git, but not in OpenWrt/LEDE yet. Please test if this fixes your issue. Thanks, - Felix Tried that but no immediate success, but it might have provided some additional clues. Now the boot hangs early on *every* boot but after logging in I found something different in the ps list. There is a Broadcom utility (smd) that is called from one of the start scripts (S10environment). It's purpose is to set scheduling priority and cpu affinity for some of the Broadcom proprietary processes, The smd program handles fork rather ugly. The parent only loops until it receives SIGCHLD and then exits without any wait. With the modified libubox I get a zombie smd child and sleeping smd parent and S11environment (no other zombie). Not sure exactly how this happened but I got to think about something written in the wait man page: """ If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies. """ Is this wait really (unconditionally) implemented in procd or could that be what I accomplished with the "forced timeout" patch? I fixed the ugly fork and got the system to boot once. Then tried the original libubox with the fixed smd program but this was not enough to get things working (25 reboots to hang). Now I'm running reboot tests with your new libubox and fixed smd... More than 250 reboots without problem :) Clearly the smd program is broken, but still it doesn't feel good that it manages to hang the init process. Considering that timing is involved it's difficult to make any certain conclusions but it seems like having uloop epoll_wait to time out occasionally isn't such a bad idea? // Mats ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
Replying to myself :) On Wed, May 18, 2016 at 10:53 AM, Radu Anghel wrote: > > step 1. add users to /etc/passwd (in the pre/post-install script > probably, trying to use same uid/gid as major distributions would be > nice) > step 2. add config option for user/group in the relevant /etc/config/ file > step 3. modify startup script to use the user/group options when > generating daemon config file > step 4. ??? > step 5. PROFIT! > This approach would also open up some interesting posibilities (interesting for me at least) like the ability to add non-privileged users that can perform configuration changes or backups but can't use sysupgrade. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, 18 May 2016, Ferry Huberts wrote: On 18/05/16 10:03, David Lang wrote: On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:46, Ferry Huberts wrote: already in-place in Fedora and RedHat/CentOS. You then get even stronger protection and run-time performance impact is negligible. the stuff i proposed has not runtime hit. selinux is simple to full SELinux's hit is for all intents and purposes zero as well nowadays. blown and hard to maintain. the idea would be to create a custom tailored solution for our requirements. That is why I prefer AppArmor, you don't have the interaction between different application configs that you do with SELinux, so you can focus on the specific application that you are concerned about. AppArmor is significantly less secure than SELinux. And with SELinux you don't need all the preloading stuff that was talked about, you can just declare which ports are allowed. tightly configured in expert hands, you are right. However, that's not the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll point out that if home users are familar with Linux, the odds are good that it's a flavor of Ubuntu that uses AA rather than Fedora that uses SELinux. (not worth much because the home user probably hasn't touched AA or SELinux) do all the compressed filesystems support the tagging needed by SELinux? what about external drives with FAT* or NTFS? How do you handle the possible need to re-label your files on a read-only filesystem? what is the difference in kernel size (and tool size) between AA and SELinux? David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, May 18, 2016 at 9:25 AM, John Crispin wrote: > > to elaborate, imagine dnsmasq running inside a jailm where ut only > thinks it is root but is not in reality. also ld-preloading bind and > connect would allow us to do pretty adavnced stuff like only allowing > dnsmasq to open certain ports. essentially an acl around the > bind/connect calls. > Doing this with a in-house developed daemon would introduce another SPOF in the same way as running everyting with the same non-root user. Imagine a security issue in such a daemon, it would affect *all* daemons running through it. This would also duplicate existing functionality (the code for dropping privileges to a preconfigured user already exists in most daemons, it is compiled as there is no --without-privileges-code ./configure option). Implementing different users with this approach can be done in a few easy steps with minor to none added overhead: step 1. add users to /etc/passwd (in the pre/post-install script probably, trying to use same uid/gid as major distributions would be nice) step 2. add config option for user/group in the relevant /etc/config/ file step 3. modify startup script to use the user/group options when generating daemon config file step 4. ??? step 5. PROFIT! I understand there are trust issues about this functionality (don't trust that the daemon really dropped all privileges), in such a case I would use SELinux. SELinux can be enabled as "permissive" until a proper policy is created for everything. There are other things to consider also, because this is supposed to run on embedded devices with as low as 4M flash space: - SELinux would increase kernel size, thus making it hard to fit inside the flash, or even bigger than the fixed kernel partition for some devices. - jails, containers and other options discussed require more memory/CPU/flash space than is probably available on said devices. Radu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
Hi again, 2016-05-18 10:22 GMT+02:00 Ferry Huberts : > > > On 18/05/16 10:03, David Lang wrote: >> >> On Wed, 18 May 2016, John Crispin wrote: >> >>> On 18/05/2016 09:46, Ferry Huberts wrote: On 18/05/16 09:25, John Crispin wrote: > > > > On 18/05/2016 09:21, Radu Anghel wrote: >> >> /* sending again because i hit 'reply' instead of 'reply all' :) */ >> >> On Wed, May 18, 2016 at 8:29 AM, John Crispin >> wrote: >>> >>> >>> ok, there had been some discussion about building a super daemon that >>> runs, then ld-preloading bind() and co and using ubus to transport >>> sockets around. using caps or /proc sounds like a good i between >>> until >>> such a daemon exists >>> >> >> Most daemons I know of that need to bind to ports <1024 start as root >> and after binding to the port they drop privileges to the privileges >> of the user specified in their config file. For those daemons just >> adding a user and specifying it in their config file should be enough. >> For the daemons that don't need to bind to <1024 just starting them >> from their own user account is ok as they don't need additional >> privileges. >> >> For example the dnsmasq daemon has these options: >> >> # If you want dnsmasq to change uid and gid to something other >> # than the default, edit the following lines. >> #user= >> #group= >> >> I don't think that integrating such functionality in ubus or some >> other LEDE-only super-daemon is a good idea. Config options + >> capabilities for those daemons withut such options is a good way of >> doing this in my opinion. Also use different users for different >> daemons, as others said. > > > to elaborate, imagine dnsmasq running inside a jailm where ut only > thinks it is root but is not in reality. also ld-preloading bind and > connect would allow us to do pretty adavnced stuff like only allowing > dnsmasq to open certain ports. essentially an acl around the > bind/connect calls. > You might just as well switch on SELinux and use the policies that are already in-place in Fedora and RedHat/CentOS. You then get even stronger protection and run-time performance impact is negligible. >>> the stuff i proposed has not runtime hit. selinux is simple to full > > > SELinux's hit is for all intents and purposes zero as well nowadays. > >>> blown and hard to maintain. the idea would be to create a custom >>> tailored solution for our requirements. >> >> >> That is why I prefer AppArmor, you don't have the interaction between >> different application configs that you do with SELinux, so you can focus >> on the specific application that you are concerned about. > > > AppArmor is significantly less secure than SELinux. > And with SELinux you don't need all the preloading stuff that was talked > about, you can just declare which ports are allowed. > >> >> SELinux configs that Fedora uses have to be so permissive to keep from >> breaking too many 'normal' use cases that I really question how valuable >> they are. > > > And this is based on what exactly? > I've been using Fedora ever since SELinux was first enabled and I don't see > that. Processes are well secured. > If you think about stuff like Firefox, then ok, that one is really hard to > secure, better run it in a sandbox. > But process that are well-defined in behaviour are well secured. > > > >> >> A SELinux system tuned by an expert is going to be more secure than an >> AppArmor system tuned by an expert, SELinux just can do more (at least >> right now). But there aren't many experts of that caliber around. A >> reasonably competent sysadmin can understand an AppArmor config and >> tweak it for their layout without too much effort (once they identify >> that AppArmor is blocking what they are trying to do) >> > > > Agreed, it is a balance. > > However, I must note that I've encountered very few cases where the policy > had to be tweaked, on my laptops, desktop and most of all servers. > > One example of tweaking is when I move a service to a different port. > That is a single command, like (moving the port of the 'cockpit' service): >> >> semanage port -a -t websm_port_t -p tcp "$newport" > > > > > My 2 cents :-) Before talking about AppArmor vs SELinux, can someone take a look at the userspace tooling size requirement ? For exemple SELinux tools are mostly Python scripts Etienne > > > > > >> David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/16 10:03, David Lang wrote: On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:46, Ferry Huberts wrote: On 18/05/16 09:25, John Crispin wrote: On 18/05/2016 09:21, Radu Anghel wrote: /* sending again because i hit 'reply' instead of 'reply all' :) */ On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: ok, there had been some discussion about building a super daemon that runs, then ld-preloading bind() and co and using ubus to transport sockets around. using caps or /proc sounds like a good i between until such a daemon exists Most daemons I know of that need to bind to ports <1024 start as root and after binding to the port they drop privileges to the privileges of the user specified in their config file. For those daemons just adding a user and specifying it in their config file should be enough. For the daemons that don't need to bind to <1024 just starting them from their own user account is ok as they don't need additional privileges. For example the dnsmasq daemon has these options: # If you want dnsmasq to change uid and gid to something other # than the default, edit the following lines. #user= #group= I don't think that integrating such functionality in ubus or some other LEDE-only super-daemon is a good idea. Config options + capabilities for those daemons withut such options is a good way of doing this in my opinion. Also use different users for different daemons, as others said. to elaborate, imagine dnsmasq running inside a jailm where ut only thinks it is root but is not in reality. also ld-preloading bind and connect would allow us to do pretty adavnced stuff like only allowing dnsmasq to open certain ports. essentially an acl around the bind/connect calls. You might just as well switch on SELinux and use the policies that are already in-place in Fedora and RedHat/CentOS. You then get even stronger protection and run-time performance impact is negligible. the stuff i proposed has not runtime hit. selinux is simple to full SELinux's hit is for all intents and purposes zero as well nowadays. blown and hard to maintain. the idea would be to create a custom tailored solution for our requirements. That is why I prefer AppArmor, you don't have the interaction between different application configs that you do with SELinux, so you can focus on the specific application that you are concerned about. AppArmor is significantly less secure than SELinux. And with SELinux you don't need all the preloading stuff that was talked about, you can just declare which ports are allowed. SELinux configs that Fedora uses have to be so permissive to keep from breaking too many 'normal' use cases that I really question how valuable they are. And this is based on what exactly? I've been using Fedora ever since SELinux was first enabled and I don't see that. Processes are well secured. If you think about stuff like Firefox, then ok, that one is really hard to secure, better run it in a sandbox. But process that are well-defined in behaviour are well secured. A SELinux system tuned by an expert is going to be more secure than an AppArmor system tuned by an expert, SELinux just can do more (at least right now). But there aren't many experts of that caliber around. A reasonably competent sysadmin can understand an AppArmor config and tweak it for their layout without too much effort (once they identify that AppArmor is blocking what they are trying to do) Agreed, it is a balance. However, I must note that I've encountered very few cases where the policy had to be tweaked, on my laptops, desktop and most of all servers. One example of tweaking is when I move a service to a different port. That is a single command, like (moving the port of the 'cockpit' service): semanage port -a -t websm_port_t -p tcp "$newport" My 2 cents :-) David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev -- Ferry Huberts ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:46, Ferry Huberts wrote: On 18/05/16 09:25, John Crispin wrote: On 18/05/2016 09:21, Radu Anghel wrote: /* sending again because i hit 'reply' instead of 'reply all' :) */ On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: ok, there had been some discussion about building a super daemon that runs, then ld-preloading bind() and co and using ubus to transport sockets around. using caps or /proc sounds like a good i between until such a daemon exists Most daemons I know of that need to bind to ports <1024 start as root and after binding to the port they drop privileges to the privileges of the user specified in their config file. For those daemons just adding a user and specifying it in their config file should be enough. For the daemons that don't need to bind to <1024 just starting them from their own user account is ok as they don't need additional privileges. For example the dnsmasq daemon has these options: # If you want dnsmasq to change uid and gid to something other # than the default, edit the following lines. #user= #group= I don't think that integrating such functionality in ubus or some other LEDE-only super-daemon is a good idea. Config options + capabilities for those daemons withut such options is a good way of doing this in my opinion. Also use different users for different daemons, as others said. to elaborate, imagine dnsmasq running inside a jailm where ut only thinks it is root but is not in reality. also ld-preloading bind and connect would allow us to do pretty adavnced stuff like only allowing dnsmasq to open certain ports. essentially an acl around the bind/connect calls. You might just as well switch on SELinux and use the policies that are already in-place in Fedora and RedHat/CentOS. You then get even stronger protection and run-time performance impact is negligible. the stuff i proposed has not runtime hit. selinux is simple to full blown and hard to maintain. the idea would be to create a custom tailored solution for our requirements. That is why I prefer AppArmor, you don't have the interaction between different application configs that you do with SELinux, so you can focus on the specific application that you are concerned about. SELinux configs that Fedora uses have to be so permissive to keep from breaking too many 'normal' use cases that I really question how valuable they are. A SELinux system tuned by an expert is going to be more secure than an AppArmor system tuned by an expert, SELinux just can do more (at least right now). But there aren't many experts of that caliber around. A reasonably competent sysadmin can understand an AppArmor config and tweak it for their layout without too much effort (once they identify that AppArmor is blocking what they are trying to do) David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:21, Radu Anghel wrote: /* sending again because i hit 'reply' instead of 'reply all' :) */ On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: ok, there had been some discussion about building a super daemon that runs, then ld-preloading bind() and co and using ubus to transport sockets around. using caps or /proc sounds like a good i between until such a daemon exists Most daemons I know of that need to bind to ports <1024 start as root and after binding to the port they drop privileges to the privileges of the user specified in their config file. For those daemons just adding a user and specifying it in their config file should be enough. For the daemons that don't need to bind to <1024 just starting them from their own user account is ok as they don't need additional privileges. For example the dnsmasq daemon has these options: # If you want dnsmasq to change uid and gid to something other # than the default, edit the following lines. #user= #group= I don't think that integrating such functionality in ubus or some other LEDE-only super-daemon is a good idea. Config options + capabilities for those daemons withut such options is a good way of doing this in my opinion. Also use different users for different daemons, as others said. to elaborate, imagine dnsmasq running inside a jailm where ut only thinks it is root but is not in reality. also ld-preloading bind and connect would allow us to do pretty adavnced stuff like only allowing dnsmasq to open certain ports. essentially an acl around the bind/connect calls. well, between the different namespace options (pid, user, network, filesystem) you can have the thing running in the container thinking that it is root and the container configuration limit what it can do. This is the bleeding edge of containerization, so advanced use cases like you are defining are going to be fragile as the kinks get worked out. But there are a lot of people working in this problem space right now. I personally think that the best bet is to ignore the problem for now, but keep an eye on the different container projects, try to make them all work on LEDE, and as the dust starts to settle, pick the top (or top few) survivors and start using them. Right now some of the namespace types open up as many vulnerabilities as they allow you to close. Another think to keep in mind is that most of these projects allow you to package up and containerize individual daemons, but as soon as you start needing to have the different things interact with each other (say the container running LUCI needs to start configuring the container running asterisk), they get really ugly. And finally, many of the people focusing on these projects are aiming for the cloud datacenter market where every machine is ephemeral and is expected to disappear and take all data/configs stored on it as it goes. So they all rely on some external storage/database setup to hold all that stuff. Not something normally available to LEDE type devices running in homes and small offices. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/2016 09:49, Etienne Champetier wrote: > Hi, > > 2016-05-18 9:25 GMT+02:00 John Crispin : >> >> >> On 18/05/2016 09:21, Radu Anghel wrote: >>> /* sending again because i hit 'reply' instead of 'reply all' :) */ >>> >>> On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: ok, there had been some discussion about building a super daemon that runs, then ld-preloading bind() and co and using ubus to transport sockets around. using caps or /proc sounds like a good i between until such a daemon exists >>> >>> Most daemons I know of that need to bind to ports <1024 start as root >>> and after binding to the port they drop privileges to the privileges >>> of the user specified in their config file. For those daemons just >>> adding a user and specifying it in their config file should be enough. >>> For the daemons that don't need to bind to <1024 just starting them >>> from their own user account is ok as they don't need additional >>> privileges. >>> >>> For example the dnsmasq daemon has these options: >>> >>> # If you want dnsmasq to change uid and gid to something other >>> # than the default, edit the following lines. >>> #user= >>> #group= >>> >>> I don't think that integrating such functionality in ubus or some >>> other LEDE-only super-daemon is a good idea. Config options + >>> capabilities for those daemons withut such options is a good way of >>> doing this in my opinion. Also use different users for different >>> daemons, as others said. >> >> to elaborate, imagine dnsmasq running inside a jailm where ut only >> thinks it is root but is not in reality. also ld-preloading bind and >> connect would allow us to do pretty adavnced stuff like only allowing >> dnsmasq to open certain ports. essentially an acl around the >> bind/connect calls. >> >> John >> > > Capabilities is the way to go. > Filesystem capabilities are painfull, so we will use process > capabilities (inherited from procd). > > I've already integrated normal capabilities in ujail, so you can run > as "reduced" root. > > You can inherit capabilities between non root user (if you have > capabilities to inherit...) but the program as to do it explicitly, > so for exemple i could (not yet supported) launch zabbix with > CAP_NET_RAW and user zabbix, but subprocess of zabbix will not be able > to use it. > > For subprocess to inherit capabilities without using root user, we > need to look into ambient capabilities (linux 4.3) > > Cheers > Etienne > Hi Etienne, i agree, for now this should be handled via caps. never heard of ambient ones, will look into that. thanks for the pointer. John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/2016 09:46, Ferry Huberts wrote: > > > On 18/05/16 09:25, John Crispin wrote: >> >> >> On 18/05/2016 09:21, Radu Anghel wrote: >>> /* sending again because i hit 'reply' instead of 'reply all' :) */ >>> >>> On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: ok, there had been some discussion about building a super daemon that runs, then ld-preloading bind() and co and using ubus to transport sockets around. using caps or /proc sounds like a good i between until such a daemon exists >>> >>> Most daemons I know of that need to bind to ports <1024 start as root >>> and after binding to the port they drop privileges to the privileges >>> of the user specified in their config file. For those daemons just >>> adding a user and specifying it in their config file should be enough. >>> For the daemons that don't need to bind to <1024 just starting them >>> from their own user account is ok as they don't need additional >>> privileges. >>> >>> For example the dnsmasq daemon has these options: >>> >>> # If you want dnsmasq to change uid and gid to something other >>> # than the default, edit the following lines. >>> #user= >>> #group= >>> >>> I don't think that integrating such functionality in ubus or some >>> other LEDE-only super-daemon is a good idea. Config options + >>> capabilities for those daemons withut such options is a good way of >>> doing this in my opinion. Also use different users for different >>> daemons, as others said. >> >> to elaborate, imagine dnsmasq running inside a jailm where ut only >> thinks it is root but is not in reality. also ld-preloading bind and >> connect would allow us to do pretty adavnced stuff like only allowing >> dnsmasq to open certain ports. essentially an acl around the >> bind/connect calls. >> > > > You might just as well switch on SELinux and use the policies that are > already in-place in Fedora and RedHat/CentOS. > > You then get even stronger protection and run-time performance impact is > negligible. > the stuff i proposed has not runtime hit. selinux is simple to full blown and hard to maintain. the idea would be to create a custom tailored solution for our requirements. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
Hi, 2016-05-18 9:25 GMT+02:00 John Crispin : > > > On 18/05/2016 09:21, Radu Anghel wrote: >> /* sending again because i hit 'reply' instead of 'reply all' :) */ >> >> On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: >>> >>> ok, there had been some discussion about building a super daemon that >>> runs, then ld-preloading bind() and co and using ubus to transport >>> sockets around. using caps or /proc sounds like a good i between until >>> such a daemon exists >>> >> >> Most daemons I know of that need to bind to ports <1024 start as root >> and after binding to the port they drop privileges to the privileges >> of the user specified in their config file. For those daemons just >> adding a user and specifying it in their config file should be enough. >> For the daemons that don't need to bind to <1024 just starting them >> from their own user account is ok as they don't need additional >> privileges. >> >> For example the dnsmasq daemon has these options: >> >> # If you want dnsmasq to change uid and gid to something other >> # than the default, edit the following lines. >> #user= >> #group= >> >> I don't think that integrating such functionality in ubus or some >> other LEDE-only super-daemon is a good idea. Config options + >> capabilities for those daemons withut such options is a good way of >> doing this in my opinion. Also use different users for different >> daemons, as others said. > > to elaborate, imagine dnsmasq running inside a jailm where ut only > thinks it is root but is not in reality. also ld-preloading bind and > connect would allow us to do pretty adavnced stuff like only allowing > dnsmasq to open certain ports. essentially an acl around the > bind/connect calls. > > John > Capabilities is the way to go. Filesystem capabilities are painfull, so we will use process capabilities (inherited from procd). I've already integrated normal capabilities in ujail, so you can run as "reduced" root. You can inherit capabilities between non root user (if you have capabilities to inherit...) but the program as to do it explicitly, so for exemple i could (not yet supported) launch zabbix with CAP_NET_RAW and user zabbix, but subprocess of zabbix will not be able to use it. For subprocess to inherit capabilities without using root user, we need to look into ambient capabilities (linux 4.3) Cheers Etienne ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/16 09:25, John Crispin wrote: On 18/05/2016 09:21, Radu Anghel wrote: /* sending again because i hit 'reply' instead of 'reply all' :) */ On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: ok, there had been some discussion about building a super daemon that runs, then ld-preloading bind() and co and using ubus to transport sockets around. using caps or /proc sounds like a good i between until such a daemon exists Most daemons I know of that need to bind to ports <1024 start as root and after binding to the port they drop privileges to the privileges of the user specified in their config file. For those daemons just adding a user and specifying it in their config file should be enough. For the daemons that don't need to bind to <1024 just starting them from their own user account is ok as they don't need additional privileges. For example the dnsmasq daemon has these options: # If you want dnsmasq to change uid and gid to something other # than the default, edit the following lines. #user= #group= I don't think that integrating such functionality in ubus or some other LEDE-only super-daemon is a good idea. Config options + capabilities for those daemons withut such options is a good way of doing this in my opinion. Also use different users for different daemons, as others said. to elaborate, imagine dnsmasq running inside a jailm where ut only thinks it is root but is not in reality. also ld-preloading bind and connect would allow us to do pretty adavnced stuff like only allowing dnsmasq to open certain ports. essentially an acl around the bind/connect calls. You might just as well switch on SELinux and use the policies that are already in-place in Fedora and RedHat/CentOS. You then get even stronger protection and run-time performance impact is negligible. John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev -- Ferry Huberts ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 09:04, David Lang wrote: The first question I would have is if we are going to the system users in an essentially random order (as needed so two systems with the same packages installed in a different order have different user->uid mapping) or if we are going to define service accounts distro wide so they are always going to be the same. what would be the pros and cons for either of those ? If you have static user allocations then LEDE needs to maintain a central repository of userids and a way for applications to be registered with it. If you have dynamic user allocations, then the package installer scripts need to have more complexity to request the userids on the fly and make everything they install have the correct permissions. (most distros take this approach) In the case of LEDE, we generally aren't running install scripts for the packages on a running system, all this happens at compile time when you don't have a way to run various tools to lookup and allocate users and set the file permissions, so I think there's a good argument that the static allocation approach would work better here. The other place where this bites people is when they have multiple systems that then need to start working together (mounting a network drive and sharing info, think high availability and similar, or copying files from one system to another and trying to use them there). The 'normal' answer is that you then need to start managing users with some new tool (Chef, Puppet, Ansible, Salt, etc) that pre-allocates the users onto the systems before the install scripts run and/or overrides the package defaults. As I say, the common choice is dynamically allocated uids, but lede has to do this at compile/image creation time instead of on a running system. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/2016 09:21, Radu Anghel wrote: > /* sending again because i hit 'reply' instead of 'reply all' :) */ > > On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: >> >> ok, there had been some discussion about building a super daemon that >> runs, then ld-preloading bind() and co and using ubus to transport >> sockets around. using caps or /proc sounds like a good i between until >> such a daemon exists >> > > Most daemons I know of that need to bind to ports <1024 start as root > and after binding to the port they drop privileges to the privileges > of the user specified in their config file. For those daemons just > adding a user and specifying it in their config file should be enough. > For the daemons that don't need to bind to <1024 just starting them > from their own user account is ok as they don't need additional > privileges. > > For example the dnsmasq daemon has these options: > > # If you want dnsmasq to change uid and gid to something other > # than the default, edit the following lines. > #user= > #group= > > I don't think that integrating such functionality in ubus or some > other LEDE-only super-daemon is a good idea. Config options + > capabilities for those daemons withut such options is a good way of > doing this in my opinion. Also use different users for different > daemons, as others said. to elaborate, imagine dnsmasq running inside a jailm where ut only thinks it is root but is not in reality. also ld-preloading bind and connect would allow us to do pretty adavnced stuff like only allowing dnsmasq to open certain ports. essentially an acl around the bind/connect calls. John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
/* sending again because i hit 'reply' instead of 'reply all' :) */ On Wed, May 18, 2016 at 8:29 AM, John Crispin wrote: > > ok, there had been some discussion about building a super daemon that > runs, then ld-preloading bind() and co and using ubus to transport > sockets around. using caps or /proc sounds like a good i between until > such a daemon exists > Most daemons I know of that need to bind to ports <1024 start as root and after binding to the port they drop privileges to the privileges of the user specified in their config file. For those daemons just adding a user and specifying it in their config file should be enough. For the daemons that don't need to bind to <1024 just starting them from their own user account is ok as they don't need additional privileges. For example the dnsmasq daemon has these options: # If you want dnsmasq to change uid and gid to something other # than the default, edit the following lines. #user= #group= I don't think that integrating such functionality in ubus or some other LEDE-only super-daemon is a good idea. Config options + capabilities for those daemons withut such options is a good way of doing this in my opinion. Also use different users for different daemons, as others said. Radu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On 18/05/2016 09:04, David Lang wrote: > > The first question I would have is if we are going to the system users > in an essentially random order (as needed so two systems with the same > packages installed in a different order have different user->uid > mapping) or if we are going to define service accounts distro wide so > they are always going to be the same. what would be the pros and cons for either of those ? John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] running stuff as !root
On Wed, 18 May 2016, John Crispin wrote: On 18/05/2016 08:09, Daniel Curran-Dickinson wrote: On 16-05-18 01:05 AM, John Crispin wrote: Hi, we had previously started building the infra for running stuff as !root. so far we have added * the userid/gid stuff * acl on ubus things that i know are missing * handling network ports < 1024 what am i missing ? can anyone think of other issues we need to address before we change uid to !root ? Er, do you mean uid of procd or ubus or everything? I'm not sure we're clear on which uid you mean? ok, my mail that sounded totally obvious to me apparently was hard to understand. right now we run $everything as root which is obviously rather daring so we need to change it to what normal distros do and run stuff as their own users wherever it makes sense and give those users only the permissions required. Ok, that makes a lot of sense. The good news here is that we don't have to start off with doing fancy stuff like passing sockets around, playing with capabilities to bind to low ports, SELinux/AppArmor, etc. We can start off by just copying the sysV init configs that have existed for other distros. Most of the work is actually going to be in undoing OpenWRT specific configs that run everything as root and fall more in line with what the other distros are doing. The first question I would have is if we are going to the system users in an essentially random order (as needed so two systems with the same packages installed in a different order have different user->uid mapping) or if we are going to define service accounts distro wide so they are always going to be the same. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
