From ziyao at disroot.org Thu Feb 2 04:55:23 2023 From: ziyao at disroot.org (Ziyao) Date: Thu, 02 Feb 2023 12:55:23 +0800 Subject: [PATCH] Fix failure to remove an empty directory without read permission Message-ID: Hi list, The applet rm fails to remove an empty directoy without read permission and just exits silently. For example, $ mkdir t && chmod 100 t $ rm -rf t # Print nothing and the directory is still there $ echo $? 1 This problem does not exist in GNU coreutils. rm invokes remove_file() to do the actual remove, which tries to open it first when removing a directory (libbb/remove_file.c:49). I guess it is for removing its contents because we cannot remove a nonempty directory. But if reading the directory is not permitted, opendir() will fail and cause rm exiting without an error message. This small patch tries to remove the directory first instead of opening it, and prints a friendly message when the opening fails instead of exiting silently. ---- diff --git a/libbb/remove_file.c b/libbb/remove_file.c index 1505e62..7bee9f0 100644 --- a/libbb/remove_file.c +++ b/libbb/remove_file.c @@ -45,8 +45,15 @@ int FAST_FUNC remove_file(const char *path, int flags) return 0; } + /* + * Handle empty directoires even if without read permission + */ + if (!rmdir(path)) + return 0; + dp = opendir(path); - if (dp == NULL) { + if (!dp) { + bb_perror_msg("can't remove '%s'",path); return -1; } -- Ziyao From farmatito at tiscali.it Thu Feb 2 07:14:20 2023 From: farmatito at tiscali.it (tito) Date: Thu, 2 Feb 2023 08:14:20 +0100 Subject: [PATCH] Fix failure to remove an empty directory without read permission In-Reply-To: References: Message-ID: <20230202081420.600a4a66@devuan> On Thu, 02 Feb 2023 12:55:23 +0800 Ziyao wrote: > Hi list, > > The applet rm fails to remove an empty directoy without read permission > and > just exits silently. > > For example, > $ mkdir t && chmod 100 t > $ rm -rf t # Print nothing and the directory is still > there > $ echo $? > 1 > > This problem does not exist in GNU coreutils. Hi, But Posix says: If file is of type directory, the following steps shall be taken: If neither the -R option nor the -r option is specified, rm shall write a diagnostic message to standard error, do nothing more with file, and go on to any remaining files. If the -f option is not specified, and either the permissions of file do not permit writing and the standard input is a terminal or the -i option is specified, rm shall write a prompt to standard error and read a line from the standard input. If the response is not affirmative, rm shall do nothing more with the current file and go on to any remaining files. so my question is: does your patch remove the dir only with -rf options or with all option combinations? Ciao, Tito > > rm invokes remove_file() to do the actual remove, which tries to open it > first when removing a directory (libbb/remove_file.c:49). I guess it is > for > removing its contents because we cannot remove a nonempty directory. > But if reading the directory is not permitted, opendir() will fail and > cause > rm exiting without an error message. > > This small patch tries to remove the directory first instead of opening > it, > and prints a friendly message when the opening fails instead of exiting > silently. > > ---- > diff --git a/libbb/remove_file.c b/libbb/remove_file.c > index 1505e62..7bee9f0 100644 > --- a/libbb/remove_file.c > +++ b/libbb/remove_file.c > @@ -45,8 +45,15 @@ int FAST_FUNC remove_file(const char *path, int > flags) > return 0; > } > > + /* > + * Handle empty directoires even if without read > permission > + */ > + if (!rmdir(path)) > + return 0; > + > dp = opendir(path); > - if (dp == NULL) { > + if (!dp) { > + bb_perror_msg("can't remove '%s'",path); > return -1; > } > > From ziyao at disroot.org Fri Feb 3 03:21:16 2023 From: ziyao at disroot.org (Ziyao) Date: Fri, 03 Feb 2023 11:21:16 +0800 Subject: [PATCH] Fix failure to remove an empty directory without read permission In-Reply-To: <20230202081420.600a4a66@devuan> References: <20230202081420.600a4a66@devuan> Message-ID: On 2023-02-02 15:14, tito wrote: > On Thu, 02 Feb 2023 12:55:23 +0800 > Hi, > But Posix says: > > If file is of type directory, the following steps shall be taken: > > If neither the -R option nor the -r option is specified, rm shall > write a diagnostic > message to standard error, do nothing more with file, and go on to > any remaining files. > > If the -f option is not specified, and either the permissions of > file do not permit writing > and the standard input is a terminal or the -i option is specified, > rm shall write > a prompt to standard error and read a line from the standard input. > If the response is not affirmative, rm shall do nothing more with > the current file and go on to any remaining files. > > so my question is: does your patch remove the dir only with -rf options > or with all option combinations? > > Ciao, > Tito Sorry, my last mail was sent to Tito only. The patch only removes the directory with -r specified. However, it does not give an additional prompt when -i is specified. Maybe the following patch is better. --- diff --git a/libbb/remove_file.c b/libbb/remove_file.c index 1505e62..7b60ab3 100644 --- a/libbb/remove_file.c +++ b/libbb/remove_file.c @@ -46,8 +46,8 @@ int FAST_FUNC remove_file(const char *path, int flags) } dp = opendir(path); - if (dp == NULL) { - return -1; + if (!dp) { + goto tryRemoveDir; } while ((d = readdir(dp)) != NULL) { @@ -62,7 +62,8 @@ int FAST_FUNC remove_file(const char *path, int flags) } closedir(dp); - if (flags & FILEUTILS_INTERACTIVE) { +tryRemoveDir: + if ((flags & FILEUTILS_INTERACTIVE)) { fprintf(stderr, "%s: remove directory '%s'? ", applet_name, path); if (!bb_ask_y_confirmation()) -- Ziyao From asmadeus at codewreck.org Fri Feb 3 03:59:56 2023 From: asmadeus at codewreck.org (Dominique Martinet) Date: Fri, 3 Feb 2023 12:59:56 +0900 Subject: [PATCH resend] sed: check errors writing file with sed -i Message-ID: <20230203035956.3663022-1-asmadeus@codewreck.org> From: Dominique Martinet sed would currently not error if write failed when modifying a file. This can be reproduced with the following 'script': $ sudo mount -t tmpfs tmpfs -o size=1M /tmp/m $ sudo chmod 777 /tmp/m $ echo foo > /tmp/m/foo $ dd if=/dev/zero of=/tmp/m/fill bs=4k dd: error writing '/tmp/m/fill': No space left on device 256+0 records in 255+0 records out 1044480 bytes (1.0 MB, 1020 KiB) copied, 0.00234567 s, 445 MB/s $ busybox sed -i -e 's/.*/bar/' /tmp/m/foo $ echo $? 0 $ cat /tmp/m/foo new behaviour: $ echo foo > /tmp/m/foo $ ./busybox sed -i -e 's/.*/bar/' /tmp/m/foo sed: write error $ echo $? 4 $ cat /tmp/m/foo foo function old new delta sed_main 754 801 +47 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/0 up/down: 47/0) Total: 47 bytes text data bss dec hex filename 66957 2398 1552 70907 114fb busybox_old 67004 2398 1552 70954 1152a busybox_unstripped Signed-off-by: Dominique Martinet --- (Denys, sorry for double-resend -- I didn't understand why I had sent this from my personal address last time but the list blocks non-subscriber mails... resending from this address again...) Not getting any reply to whether I should resend last month, so resending in doubt... FWIW this has been applied on alpine shortly after sending the patch (mid Nov), there hasn't been any problem that I've heard about. editors/sed.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/editors/sed.c b/editors/sed.c index 32a4b61f6d4c..be709eef3a9c 100644 --- a/editors/sed.c +++ b/editors/sed.c @@ -1639,6 +1639,11 @@ int sed_main(int argc UNUSED_PARAM, char **argv) fchown(nonstdoutfd, statbuf.st_uid, statbuf.st_gid); process_files(); + fflush(G.nonstdout); + if (ferror(G.nonstdout)) { + xfunc_error_retval = 4; /* It's what gnu sed exits with... */ + bb_simple_error_msg_and_die(bb_msg_write_error); + } fclose(G.nonstdout); G.nonstdout = stdout; -- 2.35.1 From kamilbaranski at gmail.com Fri Feb 3 16:47:01 2023 From: kamilbaranski at gmail.com (Kamil Baranski) Date: Fri, 3 Feb 2023 17:47:01 +0100 Subject: udhcpd logging Message-ID: Hello, I think we could log something more interesting than two messages - "found static lease: 432a8c0" and - "sending OFFER of 192.168.50.4". I'd suggest one log message: - sending [OFFER of|ACK to|etc] 192.168.50.4 (MAC: 11:22:33:44:55:66; [static|dynamic] lease) That might be useful for debugging and network administration. What do you think? Greetings! -- * Mi?ego dnia, pozdrawiam! http://kamilbaranski.com/ http://facebook.com/kamilbaranskimusic From peron.clem at gmail.com Tue Feb 7 15:11:55 2023 From: peron.clem at gmail.com (=?UTF-8?B?Q2zDqW1lbnQgUMOpcm9u?=) Date: Tue, 7 Feb 2023 16:11:55 +0100 Subject: [PATCH] udhcp: add option to set CoS priority In-Reply-To: <20221227223038.4101-1-peron.clem@gmail.com> References: <20221227223038.4101-1-peron.clem@gmail.com> Message-ID: Hi, On Tue, 7 Feb 2023 at 13:53, Cl?ment P?ron wrote: > > Some ISP, like the French ISP Orange uses DHCP messages with > a CoS Priority of 6 otherwise they are not processed. > > Add an option to allow setting this property. > > Signed-off-by: Cl?ment P?ron Sorry, unwanted resend. I have properly configured my mail client on a new computer and pending emails have been flushed out. Please ignore, Clement > --- > networking/udhcp/d6_dhcpc.c | 6 ++++++ > networking/udhcp/d6_packet.c | 14 ++++++++++++++ > networking/udhcp/dhcpc.c | 10 ++++++++++ > networking/udhcp/dhcpc.h | 2 ++ > networking/udhcp/packet.c | 16 ++++++++++++++++ > 5 files changed, 48 insertions(+) > > diff --git a/networking/udhcp/d6_dhcpc.c b/networking/udhcp/d6_dhcpc.c > index cdd06188e..675914432 100644 > --- a/networking/udhcp/d6_dhcpc.c > +++ b/networking/udhcp/d6_dhcpc.c > @@ -129,6 +129,7 @@ static const char udhcpc6_longopts[] ALIGN1 = > ) > /// IF_FEATURE_UDHCPC_ARPING("arping\0" No_argument "a") > IF_FEATURE_UDHCP_PORT("client-port\0" Required_argument "P") > + IF_FEATURE_UDHCPC_COS("cos\0" Required_argument "y") > ; > #endif > /* Must match getopt32 option string order */ > @@ -1153,6 +1154,9 @@ static void client_background(void) > ////usage: IF_FEATURE_UDHCPC_ARPING( > ////usage: "\n -a Use arping to validate offered address" > ////usage: ) > +//usage: IF_FEATURE_UDHCPC_COS( > +//usage: "\n -y PRIORITY CoS value 0 .. 7, default 0" > +//usage: ) > //usage: "\n -l Send 'information request' instead of 'solicit'" > //usage: "\n (used for servers which do not assign IPv6 addresses)" > //usage: "\n -r IPv6 Request this address ('no' to not request any IP)" > @@ -1214,6 +1218,7 @@ int udhcpc6_main(int argc UNUSED_PARAM, char **argv) > USE_FOR_MMU("b") > ///IF_FEATURE_UDHCPC_ARPING("a") > IF_FEATURE_UDHCP_PORT("P:") > + IF_FEATURE_UDHCPC_COS("y:+") > "v" > "\0" IF_UDHCP_VERBOSE("vv") /* -v is a counter */ > , udhcpc6_longopts > @@ -1223,6 +1228,7 @@ int udhcpc6_main(int argc UNUSED_PARAM, char **argv) > , &list_O > , &list_x > IF_FEATURE_UDHCP_PORT(, &str_P) > + IF_FEATURE_UDHCPC_COS(, &sk_prio) > IF_UDHCP_VERBOSE(, &dhcp_verbose) > ); > requested_ipv6 = NULL; > diff --git a/networking/udhcp/d6_packet.c b/networking/udhcp/d6_packet.c > index 142de9b43..cbe589ff7 100644 > --- a/networking/udhcp/d6_packet.c > +++ b/networking/udhcp/d6_packet.c > @@ -68,6 +68,13 @@ int FAST_FUNC d6_send_raw_packet_from_client_data_ifindex( > goto ret_msg; > } > > + IF_FEATURE_UDHCPC_COS( > + if (sk_prio) { > + if (setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &sk_prio, sizeof(sk_prio))) { > + log1s("raw: SO_PRIORITY setsockopt() failed"); > + } > + }) > + > memset(&dest_sll, 0, sizeof(dest_sll)); > memset(&packet, 0, offsetof(struct ip6_udp_d6_packet, data)); > packet.data = *d6_pkt; /* struct copy */ > @@ -153,6 +160,13 @@ int FAST_FUNC d6_send_kernel_packet_from_client_data_ifindex( > } > setsockopt_reuseaddr(fd); > > + IF_FEATURE_UDHCPC_COS( > + if (sk_prio) { > + if (setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &sk_prio, sizeof(sk_prio))) { > + log1s("raw: SO_PRIORITY setsockopt() failed"); > + } > + }) > + > memset(&sa, 0, sizeof(sa)); > sa.sin6_family = AF_INET6; > sa.sin6_port = htons(source_port); > diff --git a/networking/udhcp/dhcpc.c b/networking/udhcp/dhcpc.c > index c757fb37c..610bec427 100644 > --- a/networking/udhcp/dhcpc.c > +++ b/networking/udhcp/dhcpc.c > @@ -1085,6 +1085,13 @@ static int udhcp_raw_socket(int ifindex) > } > #endif > > +IF_FEATURE_UDHCPC_COS( > + if (sk_prio) { > + if (setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &sk_prio, sizeof(sk_prio))) { > + log1s("raw: SO_PRIORITY setsockopt() failed"); > + } > + }) > + > if (setsockopt_1(fd, SOL_PACKET, PACKET_AUXDATA) != 0) { > if (errno != ENOPROTOOPT) > log1s("can't set PACKET_AUXDATA on raw socket"); > @@ -1186,6 +1193,9 @@ static void client_background(void) > //usage: IF_FEATURE_UDHCPC_ARPING( > //usage: "\n -a[MSEC] Validate offered address with ARP ping" > //usage: ) > +//usage: IF_FEATURE_UDHCPC_COS( > +//usage: "\n -y PRIORITY CoS value 0 .. 7, default 0" > +//usage: ) > //usage: "\n -r IP Request this IP address" > //usage: "\n -o Don't request any options (unless -O is given)" > //usage: "\n -O OPT Request option OPT from server (cumulative)" > diff --git a/networking/udhcp/dhcpc.h b/networking/udhcp/dhcpc.h > index 19b054b32..171f70d7c 100644 > --- a/networking/udhcp/dhcpc.h > +++ b/networking/udhcp/dhcpc.h > @@ -7,6 +7,8 @@ > > PUSH_AND_SET_FUNCTION_VISIBILITY_TO_HIDDEN > > +IF_FEATURE_UDHCPC_COS(extern uint32_t sk_prio;) > + > struct client_data_t { > uint8_t client_mac[6]; /* Our mac address */ > IF_FEATURE_UDHCP_PORT(uint16_t port;) > diff --git a/networking/udhcp/packet.c b/networking/udhcp/packet.c > index 529978189..4cc70ba52 100644 > --- a/networking/udhcp/packet.c > +++ b/networking/udhcp/packet.c > @@ -12,6 +12,8 @@ > #include > #include > > +IF_FEATURE_UDHCPC_COS(uint32_t sk_prio;) > + > #if ENABLE_UDHCPC || ENABLE_UDHCPD > void FAST_FUNC udhcp_init_header(struct dhcp_packet *packet, char type) > { > @@ -121,6 +123,13 @@ int FAST_FUNC udhcp_send_raw_packet(struct dhcp_packet *dhcp_pkt, > goto ret_msg; > } > > + IF_FEATURE_UDHCPC_COS( > + if (sk_prio) { > + if (setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &sk_prio, sizeof(sk_prio))) { > + log1s("raw: SO_PRIORITY setsockopt() failed"); > + } > + }) > + > memset(&dest_sll, 0, sizeof(dest_sll)); > memset(&packet, 0, offsetof(struct ip_udp_dhcp_packet, data)); > packet.data = *dhcp_pkt; /* struct copy */ > @@ -207,6 +216,13 @@ int FAST_FUNC udhcp_send_kernel_packet(struct dhcp_packet *dhcp_pkt, > } > setsockopt_reuseaddr(fd); > > + IF_FEATURE_UDHCPC_COS( > + if (sk_prio) { > + if (setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &sk_prio, sizeof(sk_prio))) { > + log1s("raw: SO_PRIORITY setsockopt() failed"); > + } > + }) > + > /* If interface carrier goes down, unless we > * bind socket to a particular netdev, the packet > * can go out through another interface, eg. via > -- > 2.37.1 (Apple Git-137.1) > From macek at scripteo.cz Sat Feb 11 19:14:52 2023 From: macek at scripteo.cz (=?UTF-8?Q?Vladim=c3=adr_Macek_=28Scripteo=29?=) Date: Sat, 11 Feb 2023 20:14:52 +0100 Subject: Problem with test -r Message-ID: Hi, I'd like to report what seems to be a bug in the busybox's test command. I use the official alpine:3 docker container. The test -r does not return true even when the file is indeed readable (testing by head command). Yes, the file has an unusual set of permissions, but that does not restrict it from reading. Here's the output of the interactive container shell session: dd72078df6d2:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv drwxrwx---??? 2 setup??? project ?????? 4096 Feb 11 18:33 . drwxr-x---??? 5 setup??? project ?????? 4096 Feb 11 18:33 .. -rw-r--r--??? 1 task???? project ????? 20512 Feb 11 18:33 cnb_rate_eur_czk.csv dd72078df6d2:/task/output/files$ id uid=2001(setup) gid=2000(project) groups=2000(project) dd72078df6d2:/task/output/files$ head -1 cnb_rate_eur_czk.csv date,rate dd72078df6d2:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE dd72078df6d2:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE dd72078df6d2:/task/output/files$ which [ /usr/bin/[ dd72078df6d2:/task/output/files$ which [[ /usr/bin/[[ dd72078df6d2:/task/output/files$ ls -la /usr/bin/[* lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /usr/bin/[ -> /bin/busybox lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /usr/bin/[[ -> /bin/busybox dd72078df6d2:/task/output/files$ /bin/busybox BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. BusyBox is copyrighted by many authors between 1998-2015. Licensed under GPLv2. See source distribution for detailed copyright notices. ... Here's how the container was built: Sending build context to Docker daemon?? 25.6kB Step 1/6 : FROM alpine:3 3: Pulling from library/alpine 8921db27df28: Pulling fs layer 8921db27df28: Download complete 8921db27df28: Pull complete Digest: sha256:f271e74b17ced29b915d351685fd4644785c6d1559dd1f2d4189a5e851ef753a Status: Downloaded newer image for alpine:3 ?---> 042a816809aa Step 2/6 : LABEL maintainer="devs at project.com" ?---> Running in cbe6d0033ff3 Removing intermediate container cbe6d0033ff3 ?---> cfdded5747d9 Step 3/6 : RUN apk add --no-cache?? curl??? bash tar???? tzdata? && addgroup --gid 2000 project && adduser --uid 2001 --home / --no-create-home --ingroup project --gecos "project Setup-Teardown" --disabled-password setup? && adduser --uid 2002 --home /home/task --ingroup project --gecos "project Task" --disabled-password task ?---> Running in 4b16dff318b9 fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz (1/12) Installing ncurses-terminfo-base (6.3_p20221119-r0) (2/12) Installing ncurses-libs (6.3_p20221119-r0) (3/12) Installing readline (8.2.0-r0) (4/12) Installing bash (5.2.15-r0) Executing bash-5.2.15-r0.post-install (5/12) Installing ca-certificates (20220614-r4) (6/12) Installing brotli-libs (1.0.9-r9) (7/12) Installing nghttp2-libs (1.51.0-r0) (8/12) Installing libcurl (7.87.0-r1) (9/12) Installing curl (7.87.0-r1) (10/12) Installing libacl (2.3.1-r1) (11/12) Installing tar (1.34-r1) (12/12) Installing tzdata (2022f-r1) Executing busybox-1.35.0-r29.trigger ... From macek at scripteo.cz Sat Feb 11 19:35:40 2023 From: macek at scripteo.cz (=?UTF-8?Q?Vladim=c3=adr_Macek_=28Scripteo=29?=) Date: Sat, 11 Feb 2023 20:35:40 +0100 Subject: Problem with test -r In-Reply-To: References: Message-ID: <280abde0-741c-f159-cf7d-89cc82275497@scripteo.cz> Additional info: The test -r command started to work again after downgrading to alpine:3.13 docker image with busybox 1.32: bash-5.1$ head -1 /task/output/files/cnb_rate_eur_czk.csv? ; [ -r /task/output/files/cnb_rate_eur_czk.csv ] && echo READABLE1 ; [[ -r /task/output/files/cnb_rate_eur_czk.csv ]] && echo READABLE2 date,rate READABLE1 READABLE2 Container build log: Step 1/6 : FROM alpine:3.13 3.13: Pulling from library/alpine 72cfd02ff4d0: Pulling fs layer 72cfd02ff4d0: Verifying Checksum 72cfd02ff4d0: Download complete 72cfd02ff4d0: Pull complete Digest: sha256:469b6e04ee185740477efa44ed5bdd64a07bbdd6c7e5f5d169e540889597b911 Status: Downloaded newer image for alpine:3.13 ?---> 6b5c5e00213a Step 2/6 : LABEL maintainer="devs at project.com" ?---> Running in 33d4d3325a4c Removing intermediate container 33d4d3325a4c ?---> cc52a45921d5 Step 3/6 : RUN apk add --no-cache ??? curl ??? bash tar ??? tzdata? && addgroup --gid 2000 project && adduser --uid 2001 --home / --no-create-home --ingroup project --gecos "project Setup-Teardown" --disabled-password setup? && adduser --uid 2002 --home /home/task --ingroup project --gecos "project Task" --disabled-password task ?---> Running in 0aa074d40de9 fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/APKINDEX.tar.gz (1/12) Installing ncurses-terminfo-base (6.2_p20210109-r1) (2/12) Installing ncurses-libs (6.2_p20210109-r1) (3/12) Installing readline (8.1.0-r0) (4/12) Installing bash (5.1.16-r0) Executing bash-5.1.16-r0.post-install (5/12) Installing ca-certificates (20220614-r0) (6/12) Installing brotli-libs (1.0.9-r3) (7/12) Installing nghttp2-libs (1.42.0-r1) (8/12) Installing libcurl (7.79.1-r3) (9/12) Installing curl (7.79.1-r3) (10/12) Installing libacl (2.2.53-r0) (11/12) Installing tar (1.34-r0) (12/12) Installing tzdata (2022f-r1) Executing busybox-1.32.1-r9.trigger Thank you, Vlada On 11. 02. 23 20:14, Vladim?r Macek (Scripteo) wrote: > Hi, > > I'd like to report what seems to be a bug in the busybox's test command. I > use the official alpine:3 docker container. > > The test -r does not return true even when the file is indeed readable > (testing by head command). Yes, the file has an unusual set of permissions, > but that does not restrict it from reading. Here's the output of the > interactive container shell session: > > dd72078df6d2:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv > drwxrwx---??? 2 setup??? project ?????? 4096 Feb 11 18:33 . > drwxr-x---??? 5 setup??? project ?????? 4096 Feb 11 18:33 .. > -rw-r--r--??? 1 task???? project ????? 20512 Feb 11 18:33 cnb_rate_eur_czk.csv > > dd72078df6d2:/task/output/files$ id > uid=2001(setup) gid=2000(project) groups=2000(project) > > dd72078df6d2:/task/output/files$ head -1 cnb_rate_eur_czk.csv > date,rate > > dd72078df6d2:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE > dd72078df6d2:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE > > dd72078df6d2:/task/output/files$ which [ > /usr/bin/[ > dd72078df6d2:/task/output/files$ which [[ > /usr/bin/[[ > > dd72078df6d2:/task/output/files$ ls -la /usr/bin/[* > lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /usr/bin/[ -> > /bin/busybox > lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /usr/bin/[[ -> > /bin/busybox > > dd72078df6d2:/task/output/files$ /bin/busybox > BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. > BusyBox is copyrighted by many authors between 1998-2015. > Licensed under GPLv2. See source distribution for detailed > copyright notices. > ... > > Here's how the container was built: > > Sending build context to Docker daemon?? 25.6kB > Step 1/6 : FROM alpine:3 > 3: Pulling from library/alpine > 8921db27df28: Pulling fs layer > 8921db27df28: Download complete > 8921db27df28: Pull complete > Digest: sha256:f271e74b17ced29b915d351685fd4644785c6d1559dd1f2d4189a5e851ef753a > Status: Downloaded newer image for alpine:3 > ?---> 042a816809aa > Step 2/6 : LABEL maintainer="devs at project.com" > ?---> Running in cbe6d0033ff3 > Removing intermediate container cbe6d0033ff3 > ?---> cfdded5747d9 > Step 3/6 : RUN apk add --no-cache?? curl??? bash tar???? tzdata? && > addgroup --gid 2000 project && adduser --uid 2001 --home / --no-create-home > --ingroup project --gecos "project Setup-Teardown" --disabled-password > setup? && adduser --uid 2002 --home /home/task --ingroup project --gecos > "project Task" --disabled-password task > ?---> Running in 4b16dff318b9 > fetch https://dl-cdn.alpinelinux.org/alpine/v3.17/main/x86_64/APKINDEX.tar.gz > fetch > https://dl-cdn.alpinelinux.org/alpine/v3.17/community/x86_64/APKINDEX.tar.gz > (1/12) Installing ncurses-terminfo-base (6.3_p20221119-r0) > (2/12) Installing ncurses-libs (6.3_p20221119-r0) > (3/12) Installing readline (8.2.0-r0) > (4/12) Installing bash (5.2.15-r0) > Executing bash-5.2.15-r0.post-install > (5/12) Installing ca-certificates (20220614-r4) > (6/12) Installing brotli-libs (1.0.9-r9) > (7/12) Installing nghttp2-libs (1.51.0-r0) > (8/12) Installing libcurl (7.87.0-r1) > (9/12) Installing curl (7.87.0-r1) > (10/12) Installing libacl (2.3.1-r1) > (11/12) Installing tar (1.34-r1) > (12/12) Installing tzdata (2022f-r1) > Executing busybox-1.35.0-r29.trigger > ... > > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From yszhou4tech at gmail.com Sun Feb 12 04:30:20 2023 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Sun, 12 Feb 2023 12:30:20 +0800 Subject: [PATCH] libiproute: fix filtering ip6 route by table id Message-ID: <20230212043020.861-1-yszhou4tech@gmail.com> Otherwise - "ip -6 route show" shows routes from all tables - "ip -6 route show table 200" shows nothing function old new delta print_route 1962 1941 -21 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-21) Total: -21 bytes Signed-off-by: Yousong Zhou --- networking/libiproute/iproute.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/networking/libiproute/iproute.c b/networking/libiproute/iproute.c index 5a972f8b2..cd77f642f 100644 --- a/networking/libiproute/iproute.c +++ b/networking/libiproute/iproute.c @@ -111,15 +111,7 @@ static int FAST_FUNC print_route(const struct sockaddr_nl *who UNUSED_PARAM, if (r->rtm_flags & RTM_F_CLONED) { return 0; } - if (G_filter.tb == RT_TABLE_LOCAL) { - if (r->rtm_type != RTN_LOCAL) { - return 0; - } - } else if (G_filter.tb == RT_TABLE_MAIN) { - if (r->rtm_type == RTN_LOCAL) { - return 0; - } - } else { + if (G_filter.tb != tid) { return 0; } } From David.Laight at ACULAB.COM Mon Feb 13 09:00:47 2023 From: David.Laight at ACULAB.COM (David Laight) Date: Mon, 13 Feb 2023 09:00:47 +0000 Subject: Problem with test -r In-Reply-To: References: Message-ID: From: Vladim?r Macek > Sent: 11 February 2023 19:15 > > Hi, > > I'd like to report what seems to be a bug in the busybox's test command. I > use the official alpine:3 docker container. > > The test -r does not return true even when the file is indeed readable > (testing by head command). Yes, the file has an unusual set of permissions, > but that does not restrict it from reading. Here's the output of the > interactive container shell session: > > dd72078df6d2:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv > drwxrwx--- 2 setup project 4096 Feb 11 18:33 . > drwxr-x--- 5 setup project 4096 Feb 11 18:33 .. > -rw-r--r-- 1 task project 20512 Feb 11 18:33 cnb_rate_eur_czk.csv By the look of it the problem is that 'test -r' requires directory search access - so why not just say that. > dd72078df6d2:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE > dd72078df6d2:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE > > dd72078df6d2:/task/output/files$ which [ > /usr/bin/[ > dd72078df6d2:/task/output/files$ which [[ > /usr/bin/[[ The output from 'which' doesn't necessarily have any connection with the code any specific shell executes for a command. 'which' is a bourne shell script that is trying (and must fail) to emulate a csh builtin command. The 'test/[' command is almost certainly a shell builtin. The program in /usr/bin is almost never executed. As for '[[', IIRC that is a bash 'special' that nothing portable should be using. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From alice at ayaya.dev Mon Feb 13 09:23:56 2023 From: alice at ayaya.dev (alice) Date: Mon, 13 Feb 2023 10:23:56 +0100 Subject: Problem with test -r In-Reply-To: References: Message-ID: On Mon Feb 13, 2023 at 10:00 AM CET, David Laight wrote: > From: Vladim?r Macek > > Sent: 11 February 2023 19:15 > > > > Hi, > > > > I'd like to report what seems to be a bug in the busybox's test command. I > > use the official alpine:3 docker container. > > > > The test -r does not return true even when the file is indeed readable > > (testing by head command). Yes, the file has an unusual set of permissions, > > but that does not restrict it from reading. Here's the output of the > > interactive container shell session: > > > > dd72078df6d2:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv > > drwxrwx--- 2 setup project 4096 Feb 11 18:33 . > > drwxr-x--- 5 setup project 4096 Feb 11 18:33 .. > > -rw-r--r-- 1 task project 20512 Feb 11 18:33 cnb_rate_eur_czk.csv > > By the look of it the problem is that 'test -r' requires > directory search access - so why not just say that. > > > dd72078df6d2:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE > > dd72078df6d2:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE > > > > dd72078df6d2:/task/output/files$ which [ > > /usr/bin/[ > > dd72078df6d2:/task/output/files$ which [[ > > /usr/bin/[[ > > The output from 'which' doesn't necessarily have any connection > with the code any specific shell executes for a command. > 'which' is a bourne shell script that is trying (and must fail) to > emulate a csh builtin command. > > The 'test/[' command is almost certainly a shell builtin. > The program in /usr/bin is almost never executed. when one is using busybox ash as a shell, is /usr/bin/test (from busybox symlink) and "builtin test" not the same code in the end (same for [)? i.e. this case, which is probably using busybox ash (needs confirmation). > As for '[[', IIRC that is a bash 'special' that nothing > portable should be using. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From David.Laight at ACULAB.COM Mon Feb 13 10:10:27 2023 From: David.Laight at ACULAB.COM (David Laight) Date: Mon, 13 Feb 2023 10:10:27 +0000 Subject: Problem with test -r In-Reply-To: References: Message-ID: <63ba1a72a4594b3096f9b94300586362@AcuMS.aculab.com> From: alice > Sent: 13 February 2023 09:24 .... > > The 'test/[' command is almost certainly a shell builtin. > > The program in /usr/bin is almost never executed. > > when one is using busybox ash as a shell, is /usr/bin/test (from busybox > symlink) and "builtin test" not the same code in the end (same for [)? i.e. > this case, which is probably using busybox ash (needs confirmation). On my busbox system [ is a shell builtin and /usr/bin/[ a program. Both just call stat(filename) for test -r filename. I don't get a fail for a non-readable directory (but can only run as root). Plausibly there is some hackery involved, but putting programs like 'ash' into busybox probably requires linking them to a .o and then making most of the symbols static and renaming 'main'. So it is difficult to share the code for 'test' unless is is all moved out into a common library. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From asmadeus at codewreck.org Mon Feb 13 11:14:34 2023 From: asmadeus at codewreck.org (Dominique Martinet) Date: Mon, 13 Feb 2023 20:14:34 +0900 Subject: Problem with test -r In-Reply-To: References: Message-ID: David Laight wrote on Mon, Feb 13, 2023 at 09:00:47AM +0000: > From: Vladim?r Macek > > I'd like to report what seems to be a bug in the busybox's test command. I > > use the official alpine:3 docker container. > > > > The test -r does not return true even when the file is indeed readable > > (testing by head command). Yes, the file has an unusual set of permissions, > > but that does not restrict it from reading. Here's the output of the > > interactive container shell session: > > > > dd72078df6d2:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv > > drwxrwx--- 2 setup project 4096 Feb 11 18:33 . > > drwxr-x--- 5 setup project 4096 Feb 11 18:33 .. > > -rw-r--r-- 1 task project 20512 Feb 11 18:33 cnb_rate_eur_czk.csv > > By the look of it the problem is that 'test -r' requires > directory search access - so why not just say that. It has x on directory (both as user and group), so what's the problem? I also cannot reproduce with the same busybox version he reports using anyway, and busybox' test has not changed from 1.32 to 1.35 so I'd say "strace or it didn't happen". Could be a weird side effect of what I assume to be a volume mount for /task, how the directory was made was not specified. b4adb3ccf49f:/task/output/files$ id uid=2001(setup) gid=2000(project) groups=2000(project),2000(project) b4adb3ccf49f:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv drwxr-xr-x 1 root root 40 Feb 13 11:08 . drwxrwx--- 1 setup project 10 Feb 13 11:07 .. -rw-r--r-- 1 task project 4 Feb 13 11:01 cnb_rate_eur_czk.csv b4adb3ccf49f:/task/output/files$ busybox | head -n 1 BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. b4adb3ccf49f:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE READABLE b4adb3ccf49f:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE READABLE b4adb3ccf49f:/task/output/files$ /usr/bin/[ -r cnb_rate_eur_czk.csv ] && echo READABLE READABLE b4adb3ccf49f:/task/output/files$ cat /etc/alpine-release 3.17.2 -- Dominique From alice at ayaya.dev Mon Feb 13 11:35:30 2023 From: alice at ayaya.dev (alice) Date: Mon, 13 Feb 2023 12:35:30 +0100 Subject: Problem with test -r In-Reply-To: References: Message-ID: On Mon Feb 13, 2023 at 12:14 PM CET, Dominique Martinet wrote: > > b4adb3ccf49f:/task/output/files$ id > uid=2001(setup) gid=2000(project) groups=2000(project),2000(project) > b4adb3ccf49f:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv > drwxr-xr-x 1 root root 40 Feb 13 11:08 . > drwxrwx--- 1 setup project 10 Feb 13 11:07 .. > -rw-r--r-- 1 task project 4 Feb 13 11:01 cnb_rate_eur_czk.csv > b4adb3ccf49f:/task/output/files$ busybox | head -n 1 > BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. > b4adb3ccf49f:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE > READABLE > b4adb3ccf49f:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE > READABLE > b4adb3ccf49f:/task/output/files$ /usr/bin/[ -r cnb_rate_eur_czk.csv ] && echo READABLE > READABLE > b4adb3ccf49f:/task/output/files$ cat /etc/alpine-release > 3.17.2 this doesn't seem like accurate reproduction- the . directory is not '770' like originally. nevertheless, i can't reproduce this on any alpine version with the same directory layout in a container, so indeed, "strace or it didn't happen" is accurate. the container build output curiously has a "bash" in the list of packages installed- so i tried running this from inside bash in case the bash builtins for this were broken- no difference. > > -- > Dominique > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From macek at scripteo.cz Mon Feb 13 14:24:41 2023 From: macek at scripteo.cz (=?UTF-8?Q?Vladim=c3=adr_Macek_=28Scripteo=29?=) Date: Mon, 13 Feb 2023 15:24:41 +0100 Subject: Problem with test -r In-Reply-To: References: Message-ID: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> Thanks everyone for important pointers! The problem seems to be brought by bash between alpine official container 3.13 and any later versions. The external command /usr/bin/[ and sh/ash from busybox both work correctly, see: 5513a6a8232d:/task/output/files$ cat /etc/alpine-release 3.17.1 5513a6a8232d:/task/output/files$ busybox | head -1 BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. 5513a6a8232d:/task/output/files$ echo $BASH_VERSION 5.2.15(1)-release 5513a6a8232d:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE 5513a6a8232d:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE 5513a6a8232d:/task/output/files$ /usr/bin/[ -r cnb_rate_eur_czk.csv ] && echo READABLE READABLE 5513a6a8232d:/task/output/files$ /usr/bin/[[ -r cnb_rate_eur_czk.csv ]] && echo READABLE READABLE 5513a6a8232d:/task/output/files$ ls -la /bin/*sh lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/ash -> /bin/busybox -rwxr-xr-x??? 1 root???? root??????? 789064 Dec 14 02:37 /bin/bash lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/fdflush -> /bin/busybox lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/sh -> /bin/busybox 5513a6a8232d:/task/output/files$ /bin/sh /task/output/files $ set| head -1 BB_ASH_VERSION='1.35.0' /task/output/files $ [ -r cnb_rate_eur_czk.csv ] && echo READABLE READABLE There was a bash-5.1.16-r0 in alpine:3.13, which was the latest version, where test -r worked correctly for me. So sorry for bugging here. I need to find out now what to do next to pursue this. Thanks again, Vlada On 13. 02. 23 12:35, alice wrote:On Mon Feb 13, 2023 at 12:14 PM CET, Dominique Martinet wrote: >> b4adb3ccf49f:/task/output/files$ id >> uid=2001(setup) gid=2000(project) groups=2000(project),2000(project) >> b4adb3ccf49f:/task/output/files$ ls -lad . .. cnb_rate_eur_czk.csv >> drwxr-xr-x 1 root root 40 Feb 13 11:08 . >> drwxrwx--- 1 setup project 10 Feb 13 11:07 .. >> -rw-r--r-- 1 task project 4 Feb 13 11:01 cnb_rate_eur_czk.csv >> b4adb3ccf49f:/task/output/files$ busybox | head -n 1 >> BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. >> b4adb3ccf49f:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE >> READABLE >> b4adb3ccf49f:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE >> READABLE >> b4adb3ccf49f:/task/output/files$ /usr/bin/[ -r cnb_rate_eur_czk.csv ] && echo READABLE >> READABLE >> b4adb3ccf49f:/task/output/files$ cat /etc/alpine-release >> 3.17.2 > this doesn't seem like accurate reproduction- > the . directory is not '770' like originally. > > nevertheless, i can't reproduce this on any alpine version with the same > directory layout in a container, so indeed, "strace or it didn't happen" is > accurate. > > the container build output curiously has a "bash" in the list of packages > installed- so i tried running this from inside bash in case the bash builtins > for this were broken- no difference. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alice at ayaya.dev Mon Feb 13 15:34:28 2023 From: alice at ayaya.dev (alice) Date: Mon, 13 Feb 2023 16:34:28 +0100 Subject: Problem with test -r In-Reply-To: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> References: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> Message-ID: On Mon Feb 13, 2023 at 3:24 PM CET, Vladim?r Macek (Scripteo) wrote: > Thanks everyone for important pointers! > > The problem seems to be brought by bash between alpine official container > 3.13 and any later versions. 3.13 has the same bash version as 3.16- 3.17 has bash 5.2. so, i assume it's new in 3.17 only. > The external command /usr/bin/[ and sh/ash from busybox both work > correctly, see: > > 5513a6a8232d:/task/output/files$ cat /etc/alpine-release > 3.17.1 > > 5513a6a8232d:/task/output/files$ busybox | head -1 > BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. > > 5513a6a8232d:/task/output/files$ echo $BASH_VERSION > 5.2.15(1)-release > > 5513a6a8232d:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE > 5513a6a8232d:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE > > 5513a6a8232d:/task/output/files$ /usr/bin/[ -r cnb_rate_eur_czk.csv ] && > echo READABLE > READABLE > 5513a6a8232d:/task/output/files$ /usr/bin/[[ -r cnb_rate_eur_czk.csv ]] && > echo READABLE > READABLE > > 5513a6a8232d:/task/output/files$ ls -la /bin/*sh > lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/ash -> > /bin/busybox > -rwxr-xr-x??? 1 root???? root??????? 789064 Dec 14 02:37 /bin/bash > lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/fdflush -> > /bin/busybox > lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/sh -> > /bin/busybox > > 5513a6a8232d:/task/output/files$ /bin/sh > > /task/output/files $ set| head -1 > BB_ASH_VERSION='1.35.0' > /task/output/files $ [ -r cnb_rate_eur_czk.csv ] && echo READABLE > READABLE > > There was a bash-5.1.16-r0 in alpine:3.13, which was the latest version, > where test -r worked correctly for me. > > So sorry for bugging here. I need to find out now what to do next to pursue > this. you can probably open an issue, after checking if someone else hasn't already: https://savannah.gnu.org/support/?group=bash (i assume that's the right place.) if you get it fixed and a patch merged, i'll happily backport it to 3.17. > Thanks again, > > Vlada > From asmadeus at codewreck.org Mon Feb 13 23:22:04 2023 From: asmadeus at codewreck.org (Dominique Martinet) Date: Tue, 14 Feb 2023 08:22:04 +0900 Subject: Problem with test -r In-Reply-To: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> References: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> Message-ID: Vladim?r Macek (Scripteo) wrote on Mon, Feb 13, 2023 at 03:24:41PM +0100: > There was a bash-5.1.16-r0 in alpine:3.13, which was the latest version, > where test -r worked correctly for me. > > So sorry for bugging here. I need to find out now what to do next to pursue > this. I cannot reproduce this on alpine 3.17's bash either (with the correct directory structure this time...); but here's for the next steps anyway: - Since this would be a bash bug, start a new thread on bug-bash at gnu.org instead of this mailing list. Further analysis might show that this is not a bash bug but a problem in the underlying storage system, but let's move this forward one step at a time. - Reproduce under strace and provide the full strace.log: strace -o /tmp/strace.log bash -c '[ -r file ]; echo $?' strace might not want to run within the container without some extra privileges, it's also possible to attach your bash process from outside if that's easier, but if you can reproduce with the container running with --privileged that is probably the most straightforward. - Provide more context around the container: build log is great but a Dockerfile or the commands to run inside the container is even better. How the container is run (docker, podman as root, podman rootless with the command you use and their environment (docker info/podman info); if the data file is in a volume then what underlying filesystem it is in, and if that still produces if you copy the tree inside the containers' /tmp for example. Good luck! -- Dominique Martinet From eduncan911+busybox at gmail.com Tue Feb 14 00:10:50 2023 From: eduncan911+busybox at gmail.com (Eric Duncan) Date: Mon, 13 Feb 2023 19:10:50 -0500 Subject: How to obtain GPG Signature for Busybox downloads? Message-ID: Hello everyone: I am trying to verify busybox downloads with the signature file. https://www.busybox.net/downloads/busybox-1.36.0.tar.bz2 https://www.busybox.net/downloads/busybox-1.36.0.tar.bz2.sig $ gpg --verify busybox-1.36.0.tar.bz2.sig gpg: assuming signed data in 'busybox-1.36.0.tar.bz2' gpg: Signature made Tue Jan 3 14:30:09 2023 UTC gpg: using DSA key C9E9416F76E610DBD09D040F47B70C55ACC9965B gpg: issuer "vda.linux at googlemail.com" gpg: Can't check signature: No public key I am unable to locate the public key on busybox.net though. Tried searching public key servers without success: gpg --batch --keyserver certserver.pgp.com --recv-keys C9E9416F76E610DB gpg --batch --keyserver keyserver.ubuntu.com --recv-keys C9E9416F76E610DB gpg --batch --keyserver pool.sks-keyservers.net --recv-keys C9E9416F76E610DB I must be missing something. :) Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmadeus at codewreck.org Tue Feb 14 00:29:54 2023 From: asmadeus at codewreck.org (Dominique Martinet) Date: Tue, 14 Feb 2023 09:29:54 +0900 Subject: How to obtain GPG Signature for Busybox downloads? In-Reply-To: References: Message-ID: Eric Duncan wrote on Mon, Feb 13, 2023 at 07:10:50PM -0500: > I am trying to verify busybox downloads with the signature file. > > https://www.busybox.net/downloads/busybox-1.36.0.tar.bz2 > https://www.busybox.net/downloads/busybox-1.36.0.tar.bz2.sig > > $ gpg --verify busybox-1.36.0.tar.bz2.sig > gpg: assuming signed data in 'busybox-1.36.0.tar.bz2' > gpg: Signature made Tue Jan 3 14:30:09 2023 UTC > gpg: using DSA key C9E9416F76E610DBD09D040F47B70C55ACC9965B > gpg: issuer "vda.linux at googlemail.com" > gpg: Can't check signature: No public key > > I am unable to locate the public key on busybox.net though. Tried > searching public key servers without success: > > gpg --batch --keyserver certserver.pgp.com --recv-keys C9E9416F76E610DB > gpg --batch --keyserver keyserver.ubuntu.com --recv-keys C9E9416F76E610DB > gpg --batch --keyserver pool.sks-keyservers.net --recv-keys C9E9416F76E610DB A key's short form isn't the first 8 bytes, it's the first 4 and the last 4. You should always use the long form though as short forms keys collisions are trivial, at which point this works: $ gpg --batch --keyserver keyserver.ubuntu.com --recv-keys C9E9416F76E610DBD09D040F47B70C55ACC9965B gpg: key 47B70C55ACC9965B: "Denis Vlasenko " not changed The key can also be found directly on the busybox website: https://busybox.net/~vda/vda_pubkey.gpg Either way, if the files had been compromised an attacker could just sign the file with a new key and you've just downloaded the attacker's key; this trust model is broken. It'll be useful for the next upgrade's onwards. -- Dominique From David.Laight at ACULAB.COM Tue Feb 14 09:29:49 2023 From: David.Laight at ACULAB.COM (David Laight) Date: Tue, 14 Feb 2023 09:29:49 +0000 Subject: Problem with test -r In-Reply-To: References: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> Message-ID: From: Dominique Martinet > Sent: 13 February 2023 23:22 ... > - Reproduce under strace and provide the full strace.log: > strace -o /tmp/strace.log bash -c '[ -r file ]; echo $?' > strace might not want to run within the container without some extra > privileges, it's also possible to attach your bash process from outside > if that's easier, but if you can reproduce with the container running > with --privileged that is probably the most straightforward. If the strace just shows the stat (maybe fstatat) system call failing then the next step is to get ftrace to monitor the kernel function calls to help guess where the error comes from. That might be tricky to arrange inside the container. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) From macek at scripteo.cz Tue Feb 14 10:19:18 2023 From: macek at scripteo.cz (=?UTF-8?Q?Vladim=c3=adr_Macek_=28Scripteo=29?=) Date: Tue, 14 Feb 2023 11:19:18 +0100 Subject: Problem with test -r In-Reply-To: References: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> Message-ID: <02530e99-cb1a-20ce-234e-3cc13094bedf@scripteo.cz> [Sorry, I accidentally e-mailed only alice yesterday. Here's the corrected and extended version.] Thank you all for taking care! Today I found out that the problem lies probably in my server docker runtime or underlying system than inside the container: In attached out.txt: I tested the command line on alpine containers 3.17 down to 3.12 and you can see, the bash worked correctly for me (READABLE-INTERNAL-BASH) only in 3.13 and 3.12. There was no bash version change between alpine 3.13.12 and 3.14, when "test -r" went bad for me. So... some rogue patch to bash may have caused this? But there was a busybox version change at that time. There's no other change on my side that I'm aware of. Regular user always executes docker run. Dockerfile and Makefile are attached. make image is used to build with varied alpine version in FROM, make sh to enter the container and run commands shown in out.txt. The scripts in scripts/ are not involved in the testing, so not attached. The underlying filesystem (/var/tmp/done/project-job-dir-1095) is ext4 (Debian 10 running on metal): /var/tmp/done/project-job-dir-1095# find output/ -ls ?38537360????? 4 drwxr-x---?? 5 2001???? 2000 4096 ?no 11 20:27 output/ ?38537362????? 4 drwxrwx---?? 2 2001???? 2000 4096 ?no 11 20:27 output/files ?38537366???? 24 -rw-r--r--?? 1 2002???? 2000 20512 ?no 11 20:27 output/files/cnb_rate_gbp_czk.csv ?38537365???? 24 -rw-r--r--?? 1 2002???? 2000 20512 ?no 11 20:27 output/files/cnb_rate_eur_czk.csv ?38537364???? 24 -rw-r--r--?? 1 2002???? 2000 20512 ?no 11 20:27 output/files/cnb_rate_usd_czk.csv lsattr shows "--------------e----" for all these items. # uname -a Linux ...? 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux # dpkg -l docker.io | grep ii ii? docker.io????? 18.09.1+dfsg1-7.1+deb10u3 amd64??????? Linux container runtime BUT, i carefully transferred the job directory to my home Ubuntu system: # uname -a Linux Inspiron 5.15.0-58-generic #64-Ubuntu SMP Thu Jan 5 11:43:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux # dpkg -l docker.io | grep ii ii? docker.io????? 20.10.12-0ubuntu4 amd64??????? Linux container runtime then the new bash in alpine 3.17 in container works CORRECTLY: e7a19212db0f:/task/output/files$ echo $BASH_VERSION ; cat /etc/alpine-release ; busybox | head -1 ; cd /task/output/files/ ; [ -r cnb_rate_eur_czk.csv ] && echo READABLE-INTERNAL-BASH ; /usr/bin/[ -r cnb_rate_eur_czk.csv ] && echo READABLE-EXTERNAL ; /bin/sh -c 'echo $BB_ASH_VERSION ; [ -r cnb_rate_eur_czk.csv ] && echo READABLE-INTERNAL-SH' 5.2.15(1)-release 3.17.2 BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. READABLE-INTERNAL-BASH READABLE-EXTERNAL 1.35.0 READABLE-INTERNAL-SH Damn... :-( On 13. 02. 23 16:34, alice wrote: > On Mon Feb 13, 2023 at 3:24 PM CET, Vladim?r Macek (Scripteo) wrote: >> Thanks everyone for important pointers! >> >> The problem seems to be brought by bash between alpine official container >> 3.13 and any later versions. > 3.13 has the same bash version as 3.16- 3.17 has bash 5.2. > > so, i assume it's new in 3.17 only. > >> The external command /usr/bin/[ and sh/ash from busybox both work >> correctly, see: >> >> 5513a6a8232d:/task/output/files$ cat /etc/alpine-release >> 3.17.1 >> >> 5513a6a8232d:/task/output/files$ busybox | head -1 >> BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. >> >> 5513a6a8232d:/task/output/files$ echo $BASH_VERSION >> 5.2.15(1)-release >> >> 5513a6a8232d:/task/output/files$ [ -r cnb_rate_eur_czk.csv ] && echo READABLE >> 5513a6a8232d:/task/output/files$ [[ -r cnb_rate_eur_czk.csv ]] && echo READABLE >> >> 5513a6a8232d:/task/output/files$ /usr/bin/[ -r cnb_rate_eur_czk.csv ] && >> echo READABLE >> READABLE >> 5513a6a8232d:/task/output/files$ /usr/bin/[[ -r cnb_rate_eur_czk.csv ]] && >> echo READABLE >> READABLE >> >> 5513a6a8232d:/task/output/files$ ls -la /bin/*sh >> lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/ash -> >> /bin/busybox >> -rwxr-xr-x??? 1 root???? root??????? 789064 Dec 14 02:37 /bin/bash >> lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/fdflush -> >> /bin/busybox >> lrwxrwxrwx??? 1 root???? root??????????? 12 Jan? 9 12:46 /bin/sh -> >> /bin/busybox >> >> 5513a6a8232d:/task/output/files$ /bin/sh >> >> /task/output/files $ set| head -1 >> BB_ASH_VERSION='1.35.0' >> /task/output/files $ [ -r cnb_rate_eur_czk.csv ] && echo READABLE >> READABLE >> >> There was a bash-5.1.16-r0 in alpine:3.13, which was the latest version, >> where test -r worked correctly for me. >> >> So sorry for bugging here. I need to find out now what to do next to pursue >> this. > you can probably open an issue, after checking if someone else hasn't already: > https://savannah.gnu.org/support/?group=bash > (i assume that's the right place.) > > if you get it fixed and a patch merged, i'll happily backport it to 3.17. > >> Thanks again, >> >> Vlada >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- $ echo $BASH_VERSION ; cat /etc/alpine-release ; busybox | head -1 ; cd /task/output/files/ ; [ -r cnb_rate_eur_czk.csv ] && echo READABLE-INTERNAL-BASH ; /usr/bin/[ -r cnb_rate_eur_czk.csv ] && echo READABLE-EXTERNAL ; /bin/sh -c 'echo $BB_ASH_VERSION ; [ -r cnb_rate_eur_czk.csv ] && echo READABLE-INTERNAL-SH' 5.2.15(1)-release 3.17.1 BusyBox v1.35.0 (2022-11-19 10:13:10 UTC) multi-call binary. READABLE-EXTERNAL 1.35.0 READABLE-INTERNAL-SH 5.1.16(1)-release 3.16.4 BusyBox v1.35.0 (2022-08-01 15:14:44 UTC) multi-call binary. READABLE-EXTERNAL 1.35.0 READABLE-INTERNAL-SH 5.1.16(1)-release 3.15.7 BusyBox v1.34.1 (2022-07-19 20:11:24 UTC) multi-call binary. READABLE-EXTERNAL 1.34.1 READABLE-INTERNAL-SH 5.1.16(1)-release 3.14.9 BusyBox v1.33.1 () multi-call binary. READABLE-EXTERNAL 1.33.1 READABLE-INTERNAL-SH 5.1.16(1)-release 3.14.0 BusyBox v1.33.1 () multi-call binary. READABLE-EXTERNAL 1.33.1 READABLE-SH-INTERNAL 5.1.16(1)-release 3.13.12 BusyBox v1.32.1 () multi-call binary. READABLE-INTERNAL-BASH READABLE-EXTERNAL READABLE-INTERNAL-SH 5.0.17(1)-release 3.12.12 BusyBox v1.31.1 () multi-call binary. READABLE-INTERNAL-BASH READABLE-EXTERNAL READABLE-INTERNAL-SH -------------- next part -------------- FROM alpine:3.14.0 LABEL maintainer="devs at mixulo.com" RUN apk add --no-cache \ curl \ bash \ tar \ tzdata \ && addgroup --gid 2000 mixulo \ && adduser --uid 2001 --home / --no-create-home --ingroup mixulo --gecos "Project Setup-Teardown" --disabled-password setup \ && adduser --uid 2002 --home /home/task --ingroup mixulo --gecos "Project Task" --disabled-password task USER setup COPY ./scripts/*.sh /scripts/ # To test this container, use `-u task` parameter for `docker run` when using this. CMD /scripts/dummy.sh -------------- next part -------------- MODULE := setup-teardown REGISTRY ?= project IMAGE_NAME := $(REGISTRY)/$(MODULE) .PHONY: image push prod push push-prod run-setup run run-teardown sh BUILD_HOST := $(shell hostname --fqdn) BUILD_LOG := build-logs/docker-build-$(REGISTRY)-$(MODULE)-$(BUILD_HOST)-$(shell date +%Y%m%d-%H%M%S-%N-%Z).log BUILD_HEADER = "Image $(IMAGE_NAME) built $(shell date +"%FT%T%z") on $(BUILD_HOST) from $(shell git describe --abbrev=0 --always --dirty)" image: echo "$(BUILD_HEADER)" >>$(BUILD_LOG) docker build -t $(IMAGE_NAME) . 2>&1 | tee -a $(BUILD_LOG) clean-image: echo "$(BUILD_HEADER) (clean target)" >>$(BUILD_LOG) docker build --pull --no-cache -t $(IMAGE_NAME) . 2>&1 | tee -a $(BUILD_LOG) push: image docker push $(IMAGE_NAME) prod: image { docker tag $(IMAGE_NAME) $(IMAGE_NAME):prod 2>&1 ; echo Tagged $(IMAGE_NAME):prod ; } | tee -a $(BUILD_LOG) push-prod: prod docker push $(IMAGE_NAME):prod # Development targets RUN_FLAGS = \ --rm \ -e JOB_SPEC_inputBatchUrl \ -e JOB_SPEC_outputFilePostUrl \ -e JOB_SPEC_statusUrl \ -e TZ \ --security-opt=no-new-privileges \ -v /var/tmp/done/project-job-dir-1095:/task run-setup: docker run $(RUN_FLAGS) --network host --user setup $(RUN_ARGS) $(IMAGE_NAME) /scripts/setup.sh run: docker run $(RUN_FLAGS) --network none -e DUMMY_SLEEP=1 $(RUN_ARGS) $(IMAGE_NAME) run-teardown: docker run $(RUN_FLAGS) --network host $(IMAGE_NAME) $(RUN_ARGS) /scripts/teardown.sh sh: docker run -ti $(RUN_FLAGS) $(RUN_ARGS) $(IMAGE_NAME) /bin/bash From asmadeus at codewreck.org Tue Feb 14 11:48:25 2023 From: asmadeus at codewreck.org (Dominique Martinet) Date: Tue, 14 Feb 2023 20:48:25 +0900 Subject: Problem with test -r In-Reply-To: <02530e99-cb1a-20ce-234e-3cc13094bedf@scripteo.cz> References: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> <02530e99-cb1a-20ce-234e-3cc13094bedf@scripteo.cz> Message-ID: Vladim?r Macek (Scripteo) wrote on Tue, Feb 14, 2023 at 11:19:18AM +0100: > # dpkg -l docker.io | grep ii > ii? docker.io????? 18.09.1+dfsg1-7.1+deb10u3 amd64??????? Linux container > runtime Say no more, this is a problem in the seccomp filter for this version of docker. upstream issue: https://github.com/docker-library/ruby/issues/351 tl;dr this is a musl change, access switches to faccessat2 which isn't allowed by this version of docker. You'll have to upgrade docker, or disable seccomp filtering. Bash's access() check really is failing, so [ -r fails for this reason. -- Dominique From macek at scripteo.cz Tue Feb 14 13:40:41 2023 From: macek at scripteo.cz (=?UTF-8?Q?Vladim=c3=adr_Macek_=28Scripteo=29?=) Date: Tue, 14 Feb 2023 14:40:41 +0100 Subject: Problem with test -r In-Reply-To: References: <0a6e30f1-0e3f-ce5a-2553-c37edf879b0f@scripteo.cz> <02530e99-cb1a-20ce-234e-3cc13094bedf@scripteo.cz> Message-ID: <089a13d7-979f-2f15-ff7f-95009b708617@scripteo.cz> On 14. 02. 23 12:48, Dominique Martinet wrote: > Vladim?r Macek (Scripteo) wrote on Tue, Feb 14, 2023 at 11:19:18AM +0100: >> # dpkg -l docker.io | grep ii >> ii? docker.io????? 18.09.1+dfsg1-7.1+deb10u3 amd64??????? Linux container >> runtime > Say no more, this is a problem in the seccomp filter for this version of > docker. > > upstream issue: > https://github.com/docker-library/ruby/issues/351 > > tl;dr this is a musl change, access switches to faccessat2 which isn't > allowed by this version of docker. > > You'll have to upgrade docker, or disable seccomp filtering. > Bash's access() check really is failing, so [ -r fails for this reason. Thank you very much, Dominique! I'll stick with alpine 3.13 until I upgrade Debian to 11 and Docker 20. Vlada From vda.linux at googlemail.com Thu Feb 16 11:16:11 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 16 Feb 2023 12:16:11 +0100 Subject: [PATCH] libiproute: fix filtering ip6 route by table id In-Reply-To: <20230212043020.861-1-yszhou4tech@gmail.com> References: <20230212043020.861-1-yszhou4tech@gmail.com> Message-ID: On Sun, Feb 12, 2023 at 5:30 AM Yousong Zhou wrote: > > Otherwise > > - "ip -6 route show" shows routes from all tables > - "ip -6 route show table 200" shows nothing > > function old new delta > print_route 1962 1941 -21 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-21) Total: -21 bytes > > Signed-off-by: Yousong Zhou > --- > networking/libiproute/iproute.c | 10 +--------- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/networking/libiproute/iproute.c b/networking/libiproute/iproute.c > index 5a972f8b2..cd77f642f 100644 > --- a/networking/libiproute/iproute.c > +++ b/networking/libiproute/iproute.c > @@ -111,15 +111,7 @@ static int FAST_FUNC print_route(const struct sockaddr_nl *who UNUSED_PARAM, > if (r->rtm_flags & RTM_F_CLONED) { > return 0; > } > - if (G_filter.tb == RT_TABLE_LOCAL) { > - if (r->rtm_type != RTN_LOCAL) { > - return 0; > - } > - } else if (G_filter.tb == RT_TABLE_MAIN) { > - if (r->rtm_type == RTN_LOCAL) { > - return 0; > - } > - } else { > + if (G_filter.tb != tid) { > return 0; > } > } The very same code exists in current iproute2 git tree. Is it also buggy in the same way? iproute.c static int filter_nlmsg(struct nlmsghdr *n, struct rtattr **tb, int host_len) { struct rtmsg *r = NLMSG_DATA(n); inet_prefix dst = { .family = r->rtm_family }; inet_prefix src = { .family = r->rtm_family }; inet_prefix via = { .family = r->rtm_family }; inet_prefix prefsrc = { .family = r->rtm_family }; __u32 table; static int ip6_multiple_tables; table = rtm_get_table(r, tb); if (preferred_family != AF_UNSPEC && r->rtm_family != preferred_family) return 0; if (r->rtm_family == AF_INET6 && table != RT_TABLE_MAIN) ip6_multiple_tables = 1; if (filter.cloned == !(r->rtm_flags & RTM_F_CLONED)) return 0; if (r->rtm_family == AF_INET6 && !ip6_multiple_tables) { if (filter.tb) { if (filter.tb == RT_TABLE_LOCAL) { if (r->rtm_type != RTN_LOCAL) return 0; } else if (filter.tb == RT_TABLE_MAIN) { if (r->rtm_type == RTN_LOCAL) return 0; } else { return 0; } } } else { if (filter.tb > 0 && filter.tb != table) return 0; } From yszhou4tech at gmail.com Thu Feb 16 12:00:07 2023 From: yszhou4tech at gmail.com (Yousong Zhou) Date: Thu, 16 Feb 2023 20:00:07 +0800 Subject: [PATCH] libiproute: fix filtering ip6 route by table id In-Reply-To: References: <20230212043020.861-1-yszhou4tech@gmail.com> Message-ID: On Thu, 16 Feb 2023 at 19:16, Denys Vlasenko wrote: > > On Sun, Feb 12, 2023 at 5:30 AM Yousong Zhou wrote: > > > > Otherwise > > > > - "ip -6 route show" shows routes from all tables > > - "ip -6 route show table 200" shows nothing > > > > function old new delta > > print_route 1962 1941 -21 > > ------------------------------------------------------------------------------ > > (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-21) Total: -21 bytes > > > > Signed-off-by: Yousong Zhou > > --- > > networking/libiproute/iproute.c | 10 +--------- > > 1 file changed, 1 insertion(+), 9 deletions(-) > > > > diff --git a/networking/libiproute/iproute.c b/networking/libiproute/iproute.c > > index 5a972f8b2..cd77f642f 100644 > > --- a/networking/libiproute/iproute.c > > +++ b/networking/libiproute/iproute.c > > @@ -111,15 +111,7 @@ static int FAST_FUNC print_route(const struct sockaddr_nl *who UNUSED_PARAM, > > if (r->rtm_flags & RTM_F_CLONED) { > > return 0; > > } > > - if (G_filter.tb == RT_TABLE_LOCAL) { > > - if (r->rtm_type != RTN_LOCAL) { > > - return 0; > > - } > > - } else if (G_filter.tb == RT_TABLE_MAIN) { > > - if (r->rtm_type == RTN_LOCAL) { > > - return 0; > > - } > > - } else { > > + if (G_filter.tb != tid) { > > return 0; > > } > > } > > The very same code exists in current iproute2 git tree. > Is it also buggy in the same way? Hi Denys I checked before and iproute2 works just fine. The code is a bit different: > > iproute.c > static int filter_nlmsg(struct nlmsghdr *n, struct rtattr **tb, int host_len) > { > struct rtmsg *r = NLMSG_DATA(n); > inet_prefix dst = { .family = r->rtm_family }; > inet_prefix src = { .family = r->rtm_family }; > inet_prefix via = { .family = r->rtm_family }; > inet_prefix prefsrc = { .family = r->rtm_family }; > __u32 table; > static int ip6_multiple_tables; > > table = rtm_get_table(r, tb); > > if (preferred_family != AF_UNSPEC && r->rtm_family != preferred_family) > return 0; > > if (r->rtm_family == AF_INET6 && table != RT_TABLE_MAIN) > ip6_multiple_tables = 1; It sets ip6_multiple_tables here. > > if (filter.cloned == !(r->rtm_flags & RTM_F_CLONED)) > return 0; > > if (r->rtm_family == AF_INET6 && !ip6_multiple_tables) { So it won't go into this branch > if (filter.tb) { > if (filter.tb == RT_TABLE_LOCAL) { > if (r->rtm_type != RTN_LOCAL) > return 0; > } else if (filter.tb == RT_TABLE_MAIN) { > if (r->rtm_type == RTN_LOCAL) > return 0; > } else { > return 0; > } > } > } else { > if (filter.tb > 0 && filter.tb != table) > return 0; The check happens here. Regards, yousong > } From thomas at devoogdt.com Fri Feb 17 18:39:08 2023 From: thomas at devoogdt.com (Thomas Devoogdt) Date: Fri, 17 Feb 2023 19:39:08 +0100 Subject: [PATCH v1] miscutils/seedrng.c: fix include error on glibc < 2.25 Message-ID: <20230217183908.641332-1-thomas@devoogdt.com> From: Thomas Devoogdt getrandom() was introduced in version 3.17 of the Linux kernel. Support was added to glibc in version 2.25. https://man7.org/linux/man-pages/man2/getrandom.2.html read_new_seed will anyway fallback to /dev/{u}random if (ret != len) Signed-off-by: Thomas Devoogdt --- miscutils/seedrng.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c index 967741dc7..663fb47a4 100644 --- a/miscutils/seedrng.c +++ b/miscutils/seedrng.c @@ -42,9 +42,14 @@ #include "libbb.h" #include -#include #include +#if __GLIBC_PREREQ(2, 25) +#include +#else +#define getrandom(buf, len, flags) (-1) +#endif + #ifndef GRND_INSECURE #define GRND_INSECURE 0x0004 /* Apparently some headers don't ship with this yet. */ #endif -- 2.39.0 From rep.dot.nop at gmail.com Fri Feb 17 18:49:51 2023 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Fri, 17 Feb 2023 19:49:51 +0100 Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v1=5D_miscutils/seedrng=2Ec=3A_fix_=3Cs?= =?US-ASCII?Q?ys/random=2Eh=3E_include_error_on_glibc_=3C_2=2E25?= In-Reply-To: <20230217183908.641332-1-thomas@devoogdt.com> References: <20230217183908.641332-1-thomas@devoogdt.com> Message-ID: <7779C093-AA09-4719-B411-E47752EAA98D@gmail.com> On 17 February 2023 19:39:08 CET, Thomas Devoogdt wrote: >From: Thomas Devoogdt > >getrandom() was introduced in version 3.17 of the Linux kernel. > Support was added to glibc in version 2.25. Yeah maybe. I'd strongly advise against that. YMMV. Just disable it then TBH? thanks, From alice at ayaya.dev Fri Feb 17 18:50:06 2023 From: alice at ayaya.dev (alice) Date: Fri, 17 Feb 2023 19:50:06 +0100 Subject: [PATCH v1] miscutils/seedrng.c: fix include error on glibc < 2.25 In-Reply-To: <20230217183908.641332-1-thomas@devoogdt.com> References: <20230217183908.641332-1-thomas@devoogdt.com> Message-ID: On Fri Feb 17, 2023 at 7:39 PM CET, Thomas Devoogdt wrote: > From: Thomas Devoogdt > > getrandom() was introduced in version 3.17 of the Linux kernel. > Support was added to glibc in version 2.25. > > https://man7.org/linux/man-pages/man2/getrandom.2.html > > read_new_seed will anyway fallback to /dev/{u}random if (ret != len) > > Signed-off-by: Thomas Devoogdt > --- > miscutils/seedrng.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c > index 967741dc7..663fb47a4 100644 > --- a/miscutils/seedrng.c > +++ b/miscutils/seedrng.c > @@ -42,9 +42,14 @@ > #include "libbb.h" > > #include > -#include > #include > > +#if __GLIBC_PREREQ(2, 25) iirc this macro is not portable, you have to first check if it is defined, no? > +#include > +#else > +#define getrandom(buf, len, flags) (-1) > +#endif > + > #ifndef GRND_INSECURE > #define GRND_INSECURE 0x0004 /* Apparently some headers don't ship with this yet. */ > #endif > -- > 2.39.0 From thomas at devoogdt.com Fri Feb 17 19:25:21 2023 From: thomas at devoogdt.com (Thomas Devoogdt) Date: Fri, 17 Feb 2023 20:25:21 +0100 Subject: [PATCH v2] miscutils/seedrng.c: fix include error on glibc < 2.25 Message-ID: <20230217192521.648817-1-thomas@devoogdt.com> From: Thomas Devoogdt getrandom() was introduced in version 3.17 of the Linux kernel. Support was added to glibc in version 2.25. https://man7.org/linux/man-pages/man2/getrandom.2.html read_new_seed will anyway fallback to /dev/{u}random if (ret != len) Signed-off-by: Thomas Devoogdt --- v2: - check if __GLIBC_PREREQ is defined - assume by default that we have --- miscutils/seedrng.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c index 967741dc7..91c93bdad 100644 --- a/miscutils/seedrng.c +++ b/miscutils/seedrng.c @@ -42,9 +42,21 @@ #include "libbb.h" #include -#include #include +#define HAVE_SYS_RANDOM 1 +#if defined(__GLIBC_PREREQ) +#if !__GLIBC_PREREQ(2, 25) +#undef HAVE_SYS_RANDOM +#endif +#endif + +#if defined(HAVE_SYS_RANDOM) +#include +#else +#define getrandom(buf, len, flags) (-1) +#endif + #ifndef GRND_INSECURE #define GRND_INSECURE 0x0004 /* Apparently some headers don't ship with this yet. */ #endif -- 2.39.2 From steffen at sdaoden.eu Fri Feb 17 19:32:43 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 17 Feb 2023 20:32:43 +0100 Subject: [PATCH v2] miscutils/seedrng.c: fix include error on glibc < 2.25 In-Reply-To: <20230217192521.648817-1-thomas@devoogdt.com> References: <20230217192521.648817-1-thomas@devoogdt.com> Message-ID: <20230217193243.XFI3s%steffen@sdaoden.eu> Ach, if he would have kept that "cat STUFF > /dev/u?random". Is there really a technical reason to require a special program. That is so un-UNIXish. There was a syscall even earlier, but, you know. #include int main(void){ char buf[256]; syscall(SYS_getrandom, buf, sizeof buf, 0); return 0; } --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From thomas at devoogdt.com Fri Feb 17 19:39:19 2023 From: thomas at devoogdt.com (Thomas Devoogdt) Date: Fri, 17 Feb 2023 20:39:19 +0100 Subject: [PATCH v2] miscutils/seedrng.c: fix include error on glibc < 2.25 In-Reply-To: <20230217193243.XFI3s%steffen@sdaoden.eu> References: <20230217192521.648817-1-thomas@devoogdt.com> <20230217193243.XFI3s%steffen@sdaoden.eu> Message-ID: Hi, Perhaps the whole function should be rewritten to simply fallback to that syscall rather than directly fallback to /dev/random? Or should I replace the define (-1) by that syscall? Kr, Thomas Op vr 17 feb. 2023 20:32 schreef Steffen Nurpmeso : > Ach, if he would have kept that "cat STUFF > /dev/u?random". > Is there really a technical reason to require a special program. > That is so un-UNIXish. > > There was a syscall even earlier, but, you know. > > #include > int main(void){ > char buf[256]; > syscall(SYS_getrandom, buf, sizeof buf, 0); > return 0; > } > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Feb 17 19:57:22 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 17 Feb 2023 20:57:22 +0100 Subject: [PATCH v2] miscutils/seedrng.c: fix include error on glibc < 2.25 In-Reply-To: References: <20230217192521.648817-1-thomas@devoogdt.com> <20230217193243.XFI3s%steffen@sdaoden.eu> Message-ID: <20230217195722.8JQUt%steffen@sdaoden.eu> Thomas Devoogdt wrote in : |Perhaps the whole function should be rewritten to simply fallback to that |syscall rather than directly fallback to /dev/random? Better not. |Or should I replace the define (-1) by that syscall? It was more a well hm joke. But i have fill = su_RANDOM_GETRANDOM_FUN(rdp->b8, a_RANDOM_SEED_BYTES); coming from #define su_RANDOM_GETRANDOM_FUN(B,S) getrandom(B, S, 0) #define su_RANDOM_GETRANDOM_H ' <<\! or #define su_RANDOM_GETRANDOM_FUN(B,S) syscall(SYS_getrandom, B, S, 0) #define su_RANDOM_GETRANDOM_H ' <<\! but configure-time (and user choosable). I mean, busybox _does_ use syscall(2) in a few places, looking for SYS_getrandom and trying that would be just one more use case. Years passed in between the syscall and the glibc. Having said that, simply going /dev/random (or even /dev/urandom, possibly, maybe, now i had to check the kernel sources) after getrandom is imho complication enough for this thing. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From thomas at devoogdt.com Fri Feb 17 20:17:28 2023 From: thomas at devoogdt.com (thomas at devoogdt.com) Date: Fri, 17 Feb 2023 21:17:28 +0100 Subject: [PATCH v3] miscutils/seedrng.c: fix include error on glibc < 2.25 Message-ID: <20230217201728.207629-1-thomas@devoogdt.com> From: Thomas Devoogdt getrandom() was introduced in version 3.17 of the Linux kernel. Support was added to glibc in version 2.25. https://man7.org/linux/man-pages/man2/getrandom.2.html read_new_seed will anyway fallback to /dev/{u}random if (ret != len) Signed-off-by: Thomas Devoogdt --- v2: - check if __GLIBC_PREREQ is defined - assume by default that we have v3: - errno was not set, so is_creditable was never true --- miscutils/seedrng.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c index 967741dc7..0d105f005 100644 --- a/miscutils/seedrng.c +++ b/miscutils/seedrng.c @@ -42,9 +42,19 @@ #include "libbb.h" #include -#include #include +#define HAVE_SYS_RANDOM_H 1 +#if defined(__GLIBC_PREREQ) +#if !__GLIBC_PREREQ(2, 25) +#undef HAVE_SYS_RANDOM_H +#endif +#endif + +#if defined(HAVE_SYS_RANDOM_H) +#include +#endif + #ifndef GRND_INSECURE #define GRND_INSECURE 0x0004 /* Apparently some headers don't ship with this yet. */ #endif @@ -81,13 +91,15 @@ static size_t determine_optimal_seed_len(void) static bool read_new_seed(uint8_t *seed, size_t len) { bool is_creditable; - ssize_t ret; - ret = getrandom(seed, len, GRND_NONBLOCK); +#if defined(HAVE_SYS_RANDOM_H) + ssize_t ret = getrandom(seed, len, GRND_NONBLOCK); if (ret == (ssize_t)len) { return true; } - if (ret < 0 && errno == ENOSYS) { + if (ret < 0 && errno == ENOSYS) +#endif + { int fd = xopen("/dev/random", O_RDONLY); struct pollfd random_fd; random_fd.fd = fd; @@ -96,11 +108,14 @@ static bool read_new_seed(uint8_t *seed, size_t len) //This is racy. is_creditable can be set to true here, but other process //can consume "good" random data from /dev/urandom before we do it below. close(fd); - } else { + } +#if defined(HAVE_SYS_RANDOM_H) + else { if (getrandom(seed, len, GRND_INSECURE) == (ssize_t)len) return false; is_creditable = false; } +#endif /* Either getrandom() is not implemented, or * getrandom(GRND_INSECURE) did not give us LEN bytes. -- 2.34.1 From thomas at devoogdt.com Sat Feb 18 12:32:36 2023 From: thomas at devoogdt.com (Thomas Devoogdt) Date: Sat, 18 Feb 2023 13:32:36 +0100 Subject: [PATCH v4] miscutils/seedrng.c: fix include error on glibc < 2.25 In-Reply-To: <20230217201728.207629-1-thomas@devoogdt.com> References: <20230217201728.207629-1-thomas@devoogdt.com> Message-ID: <20230218123236.1210239-1-thomas@devoogdt.com> From: Thomas Devoogdt getrandom() was introduced in version 3.17 of the Linux kernel. Support was added to glibc in version 2.25. https://man7.org/linux/man-pages/man2/getrandom.2.html read_new_seed will anyway fallback to /dev/{u}random if (ret != len) Signed-off-by: Thomas Devoogdt --- v2: - check if __GLIBC_PREREQ is defined - assume by default that we have v3: - errno was not set, so is_creditable was never true v4: - fixed some whitespaces --- miscutils/seedrng.c | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c index 967741dc7..0091e63e9 100644 --- a/miscutils/seedrng.c +++ b/miscutils/seedrng.c @@ -42,12 +42,21 @@ #include "libbb.h" #include -#include #include +#define HAVE_SYS_RANDOM_H 1 +#if defined(__GLIBC_PREREQ) +#if !__GLIBC_PREREQ(2, 25) +#undef HAVE_SYS_RANDOM_H +#endif +#endif + +#if defined(HAVE_SYS_RANDOM_H) +#include #ifndef GRND_INSECURE #define GRND_INSECURE 0x0004 /* Apparently some headers don't ship with this yet. */ #endif +#endif #define DEFAULT_SEED_DIR "/var/lib/seedrng" #define CREDITABLE_SEED_NAME "seed.credit" @@ -81,13 +90,15 @@ static size_t determine_optimal_seed_len(void) static bool read_new_seed(uint8_t *seed, size_t len) { bool is_creditable; - ssize_t ret; - ret = getrandom(seed, len, GRND_NONBLOCK); +#if defined(HAVE_SYS_RANDOM_H) + ssize_t ret = getrandom(seed, len, GRND_NONBLOCK); if (ret == (ssize_t)len) { return true; } - if (ret < 0 && errno == ENOSYS) { + if (ret < 0 && errno == ENOSYS) +#endif + { int fd = xopen("/dev/random", O_RDONLY); struct pollfd random_fd; random_fd.fd = fd; @@ -96,11 +107,14 @@ static bool read_new_seed(uint8_t *seed, size_t len) //This is racy. is_creditable can be set to true here, but other process //can consume "good" random data from /dev/urandom before we do it below. close(fd); - } else { + } +#if defined(HAVE_SYS_RANDOM_H) + else { if (getrandom(seed, len, GRND_INSECURE) == (ssize_t)len) return false; is_creditable = false; } +#endif /* Either getrandom() is not implemented, or * getrandom(GRND_INSECURE) did not give us LEN bytes. -- 2.34.1 From arsen at gentoo.org Tue Feb 21 19:20:31 2023 From: arsen at gentoo.org (=?UTF-8?q?Arsen=20Arsenovi=C4=87?=) Date: Tue, 21 Feb 2023 20:20:31 +0100 Subject: [PATCH] fixdep: avoid underflow when end of entry doesn't coincide with EOF Message-ID: <20230221192030.3729279-1-arsen@gentoo.org> Bug: https://bugs.gentoo.org/893776 Closes: https://bugs.busybox.net/show_bug.cgi?id=15326 Signed-off-by: Arsen Arsenovi? --- Hi, This is a fix for the recently reported scandep-related build failure. The linked Gentoo bug also includes a write-up explaining how the error happens. Thanks in advance, have a lovely day. scripts/basic/fixdep.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c index 426b4888b..66be73aad 100644 --- a/scripts/basic/fixdep.c +++ b/scripts/basic/fixdep.c @@ -338,6 +338,11 @@ void parse_dep_file(void *map, size_t len) do p--; while (!isalnum((unsigned char)*p)); p++; } + if (p < m) { + /* we've consumed the last filename of this list + already. */ + break; + } memcpy(s, m, p-m); s[p-m] = 0; if (strrcmp(s, "include/autoconf.h") && strrcmp(s, "arch/um/include/uml-config.h") && -- 2.39.2 From mmayer at broadcom.com Wed Feb 22 22:25:56 2023 From: mmayer at broadcom.com (Markus Mayer) Date: Wed, 22 Feb 2023 14:25:56 -0800 Subject: Busybox build error with glibc < 2.25 Message-ID: Hi all, With busybox 1.36.0, we are seeing the following build error if the target system is using glibc older than 2.25. CC coreutils/printf.o miscutils/seedrng.c:45:24: fatal error: sys/random.h: No such file or directory #include ^ compilation terminated. scripts/Makefile.build:197: recipe for target 'miscutils/seedrng.o' failed make[5]: *** [miscutils/seedrng.o] Error 1 Aside from the missing header file, this would subsequently be followed by a linker error that getrandom() is an unknown symbol. On systems with a newer glibc (>= 2.25), all is well. This problem happens, because getrandom() is only provided by glibc 2.25 or newer. The kernel supports it as of 3.17, so there is a version gap where the kernel provides this syscall, but glibc doesn't provide an interface for it. This seems somewhat problematic. A stub like this (with some tweaks to how header files are being included) would allow things to build (and work) as intended: ssize_t getrandom(void *buffer, size_t length, unsigned int flags) { #ifdef __NR_getrandom return syscall(__NR_getrandom, buffer, length, flags); #else /* For kernels that don't support getrandom() (< 3.17). */ errno = ENOSYS; return -1; #endif } However, to add such a stub (and to prevent including sys/random.h) when needed, the build process would need to detect the necessity for this workaround. However, there seems to be no "configure" stage in Busybox, so I am not sure how this pre-build detection can be accomplished. We'd need to compile and link a test program that tries to use getrandom() and make decisions based on the outcome. But how? Do you have any suggestions how Busybox could provide an implementation of the getrandom() system call if glibc does not? Regards, -Markus From rep.dot.nop at gmail.com Thu Feb 23 08:28:35 2023 From: rep.dot.nop at gmail.com (Bernhard Reutner-Fischer) Date: Thu, 23 Feb 2023 09:28:35 +0100 Subject: [PATCH] fixdep: avoid underflow when end of entry doesn't coincide with EOF In-Reply-To: <20230221192030.3729279-1-arsen@gentoo.org> References: <20230221192030.3729279-1-arsen@gentoo.org> Message-ID: <20230223092835.26cb5c73@nbbrfq> Hi Arsen! On Tue, 21 Feb 2023 20:20:31 +0100 Arsen Arsenovi? wrote: > Bug: https://bugs.gentoo.org/893776 > Closes: https://bugs.busybox.net/show_bug.cgi?id=15326 > Signed-off-by: Arsen Arsenovi? > --- > Hi, > > This is a fix for the recently reported scandep-related build failure. > The linked Gentoo bug also includes a write-up explaining how the error > happens. I think we lifted fixdep from the kernel, either linux/scripts/basic/fixdep.c or linux/tools/build/fixdep.c Can you see if we diverged in other ways, too, or if any of the linux ones suffer from the same problem? That said, i think it would be worthwhile (and overdue) to update our kconfig as a whole, but that's some work.. In f3d1e213fef45ba2df4090e9cd02217d1ef82f00 i pulled check-lxdialog from linux-2.6.26 I guess Denys used kconfig from around 2.6.17 initially and i fear we never really updated it in busybox. I did update it in buildroot once or twice and, way back then, stored the buildroot specific diff to ease future updates. But i fear we never did this in busybox :-/ But checking 7d219aab70e6951ab82c27c202cac05016696723 against the one in 2.6.17-ish might be a start. Or, of course, just sit down and do a sweeping update to the current kconfig and bring forward the necessary busybox specific bits. Maybe someone volunteers to have a look? cheers, > > Thanks in advance, have a lovely day. > > scripts/basic/fixdep.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c > index 426b4888b..66be73aad 100644 > --- a/scripts/basic/fixdep.c > +++ b/scripts/basic/fixdep.c > @@ -338,6 +338,11 @@ void parse_dep_file(void *map, size_t len) > do p--; while (!isalnum((unsigned char)*p)); > p++; > } > + if (p < m) { > + /* we've consumed the last filename of this list > + already. */ > + break; > + } > memcpy(s, m, p-m); s[p-m] = 0; > if (strrcmp(s, "include/autoconf.h") && > strrcmp(s, "arch/um/include/uml-config.h") && From rmy at pobox.com Thu Feb 23 09:03:06 2023 From: rmy at pobox.com (Ron Yorston) Date: Thu, 23 Feb 2023 09:03:06 +0000 Subject: [PATCH] fixdep: avoid underflow when end of entry doesn't coincide with EOF In-Reply-To: <20230223092835.26cb5c73@nbbrfq> References: <20230221192030.3729279-1-arsen@gentoo.org> <20230223092835.26cb5c73@nbbrfq> Message-ID: <63f72bca.9mHQpZhiptYkTSRF%rmy@pobox.com> Bernhard Reutner-Fischer wrote: >Or, of course, just sit down and do a sweeping update >to the current kconfig and bring forward the necessary busybox specific >bits. Maybe someone volunteers to have a look? Xabier Oneca posted an RFC patch set in 2021: http://lists.busybox.net/pipermail/busybox/2021-May/089589.html I reviewed it in 2022 when it popped up in my inbox for some reason: http://lists.busybox.net/pipermail/busybox/2022-April/089597.html Ron From thomas at devoogdt.com Thu Feb 23 13:17:36 2023 From: thomas at devoogdt.com (Thomas Devoogdt) Date: Thu, 23 Feb 2023 14:17:36 +0100 Subject: Busybox build error with glibc < 2.25 Message-ID: Hi, This is the same issue for which I added a patch a few days ago: http://lists.busybox.net/pipermail/busybox/2023-February/090172.html Perhaps, that last patch got lost through all my trial-and-error revisions. I've tested it on a 2.6.37 kernel and on my Ubuntu 2022.04 where I compiled it twice, once with HAVE_SYS_RANDOM_H, and a second time without. (using #undef) kr, Thomas Devoogdt From arsen at gentoo.org Thu Feb 23 13:35:41 2023 From: arsen at gentoo.org (Arsen =?utf-8?Q?Arsenovi=C4=87?=) Date: Thu, 23 Feb 2023 14:35:41 +0100 Subject: [PATCH] fixdep: avoid underflow when end of entry doesn't coincide with EOF In-Reply-To: <20230223092835.26cb5c73@nbbrfq> References: <20230221192030.3729279-1-arsen@gentoo.org> <20230223092835.26cb5c73@nbbrfq> Message-ID: <861qmgcwz9.fsf@gentoo.org> Hi Bernhard, Bernhard Reutner-Fischer writes: > Hi Arsen! > > On Tue, 21 Feb 2023 20:20:31 +0100 > Arsen Arsenovi? wrote: > >> Bug: https://bugs.gentoo.org/893776 >> Closes: https://bugs.busybox.net/show_bug.cgi?id=15326 >> Signed-off-by: Arsen Arsenovi? >> --- >> Hi, >> >> This is a fix for the recently reported scandep-related build failure. >> The linked Gentoo bug also includes a write-up explaining how the error >> happens. > > I think we lifted fixdep from the kernel, either > linux/scripts/basic/fixdep.c > or > linux/tools/build/fixdep.c > > Can you see if we diverged in other ways, too, or if any of the linux > ones suffer from the same problem? The Linux one appears to not exhibit the crash on this edge case: /tmp/busybox $ ../linux/scripts/basic/fixdep foo \ scripts/kconfig/kxgettext.o \ foobar /tmp/busybox $ scripts/basic/fixdep foo \ scripts/kconfig/kxgettext.o \ foobar *** buffer overflow detected ***: terminated Aborted (core dumped) /tmp/busybox 134 $ I hadn't checked there before, since I didn't realize this was shared code. > That said, i think it would be worthwhile (and overdue) to update our > kconfig as a whole, but that's some work.. > > In f3d1e213fef45ba2df4090e9cd02217d1ef82f00 i pulled check-lxdialog > from linux-2.6.26 > I guess Denys used kconfig from around 2.6.17 initially and i fear we > never really updated it in busybox. I did update it in buildroot once > or twice and, way back then, stored the buildroot specific diff to ease > future updates. But i fear we never did this in busybox :-/ But checking > 7d219aab70e6951ab82c27c202cac05016696723 against the one in 2.6.17-ish > might be a start. Or, of course, just sit down and do a sweeping update > to the current kconfig and bring forward the necessary busybox specific > bits. Maybe someone volunteers to have a look? fixdep.c seems to have accumulated a lot of change over the years indeed, it's even using mmap now! It's indeed probably worthwhile updating. The patch I posted could still be a useful hotfix in the meanwhile, but I'm afraid that I can't help much with Kconfig, it mostly goes over my head :) Thanks, have a lovely day. -- Arsen Arsenovi? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 381 bytes Desc: not available URL: From mmayer at broadcom.com Fri Feb 24 22:50:16 2023 From: mmayer at broadcom.com (Markus Mayer) Date: Fri, 24 Feb 2023 14:50:16 -0800 Subject: Busybox build error with glibc < 2.25 In-Reply-To: References: Message-ID: Hi Thomas, My apologies for replying to my own e-mail rather than yours. Somehow I never received a copy of your email in my inbox. I had to read it via the web archive. This also means I don't know the message's ID for me to reply to it directly. I came up with a solution as well. The difference in my approach is that I am *PROVIDING* the missing getrandom() system call if glibc doesn't offer it. Therefore, only if glibc doesn't provide it *AND* the kernel doesn't provide it would seedrng have to go without the getrandom() implementation. I think this is the main benefit of my proposal. It won't make a difference with 2.6 kernels, but if one were to use, say, kernel 4.1 with glibc 2.24, one would definitely benefit from being able to use getrandom(), even if glibc doesn't offer it. It's in the kernel, after all. I haven't made any tweaks to seedrng directly (outside of handling the alternate source of getrandom()). There may be some room for improvement there. So far, my proposal also doesn't address uclibc or musl-libc. I'll be sending the patch itself in a new thread shortly to solicit some feedback. I don't want the submission to get lost in a thread that started out without any patch attached, so I am not including the proposed code changes here. Regards, -Markus From mmayer at broadcom.com Fri Feb 24 22:51:42 2023 From: mmayer at broadcom.com (Markus Mayer) Date: Fri, 24 Feb 2023 14:51:42 -0800 Subject: [PATCH] miscutil: provide getrandom() userland implementation if needed In-Reply-To: References: Message-ID: <20230224225142.2555427-1-mmayer@broadcom.com> Glibc 2.24 and older do not provide an interface for the getrandom() system call. Linux kernels have been implementing this sytem call since kernel 3.17. Let's address the situation where glibc <= 2.24 and Linux >= 3.17 by providing the system call interface ourselves when needed. This allows users to take advantage of getrandom() as long as the kernel supports it, even if glibc doesn't provide access to it. Signed-off-by: Markus Mayer --- miscutils/getrandom.c | 22 ++++++++++++++++++++++ miscutils/random.h | 19 +++++++++++++++++++ miscutils/seedrng.c | 6 +++++- 3 files changed, 46 insertions(+), 1 deletion(-) create mode 100644 miscutils/getrandom.c create mode 100644 miscutils/random.h diff --git a/miscutils/getrandom.c b/miscutils/getrandom.c new file mode 100644 index 000000000000..ab6a57f8042e --- /dev/null +++ b/miscutils/getrandom.c @@ -0,0 +1,22 @@ +#include + +#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ <= 24 + +#ifndef __NR_getrandom +#include +#endif +#include +#include "random.h" + +ssize_t getrandom(void *buffer, size_t length, unsigned int flags) +{ +#ifdef __NR_getrandom + return syscall(__NR_getrandom, buffer, length, flags); +#else + /* For kernels that don't support getrandom() (< 3.17). */ + errno = ENOSYS; + return -1; +#endif +} + +#endif /* __GLIBC__ ... */ diff --git a/miscutils/random.h b/miscutils/random.h new file mode 100644 index 000000000000..3131df5e8a5d --- /dev/null +++ b/miscutils/random.h @@ -0,0 +1,19 @@ +#ifndef _RANDOM_H +#define _RANDOM_H 1 + +#include +#include + +#ifndef GRND_NONBLOCK +#define GRND_NONBLOCK 0x01 +#endif +#ifndef GRND_RANDOM +#define GRND_RANDOM 0x02 +#endif +#ifndef GRND_INSECURE +#define GRND_INSECURE 0x04 +#endif + +ssize_t getrandom(void *buffer, size_t length, unsigned int flags); + +#endif /* _RANDOM_H */ diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c index 967741dc72ea..8ce553e460b1 100644 --- a/miscutils/seedrng.c +++ b/miscutils/seedrng.c @@ -29,7 +29,7 @@ //applet:IF_SEEDRNG(APPLET(seedrng, BB_DIR_USR_SBIN, BB_SUID_DROP)) -//kbuild:lib-$(CONFIG_SEEDRNG) += seedrng.o +//kbuild:lib-$(CONFIG_SEEDRNG) += getrandom.o seedrng.o //usage:#define seedrng_trivial_usage //usage: "[-d DIR] [-n]" @@ -42,7 +42,11 @@ #include "libbb.h" #include +#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ <= 24 +#include "random.h" +#else #include +#endif #include #ifndef GRND_INSECURE -- 2.34.1 From thomas at devoogdt.com Sun Feb 26 17:23:40 2023 From: thomas at devoogdt.com (Thomas Devoogdt) Date: Sun, 26 Feb 2023 18:23:40 +0100 Subject: [PATCH] miscutil: provide getrandom() userland implementation if needed In-Reply-To: <20230224225142.2555427-1-mmayer@broadcom.com> References: <20230224225142.2555427-1-mmayer@broadcom.com> Message-ID: Hi, This solution is equally correct, the most crucial thing here is that `errno = ENOSYS;` is set so that the /dev/random fallback is used. All other stuff is coding style, but I would personally already put the include in "random.h". So that only one time the glibc and kernel version check is needed. kr, Thomas Op vr 24 feb. 2023 om 23:52 schreef Markus Mayer : > > Glibc 2.24 and older do not provide an interface for the getrandom() > system call. Linux kernels have been implementing this sytem call since > kernel 3.17. > > Let's address the situation where glibc <= 2.24 and Linux >= 3.17 by > providing the system call interface ourselves when needed. This allows > users to take advantage of getrandom() as long as the kernel supports > it, even if glibc doesn't provide access to it. > > Signed-off-by: Markus Mayer > --- > miscutils/getrandom.c | 22 ++++++++++++++++++++++ > miscutils/random.h | 19 +++++++++++++++++++ > miscutils/seedrng.c | 6 +++++- > 3 files changed, 46 insertions(+), 1 deletion(-) > create mode 100644 miscutils/getrandom.c > create mode 100644 miscutils/random.h > > diff --git a/miscutils/getrandom.c b/miscutils/getrandom.c > new file mode 100644 > index 000000000000..ab6a57f8042e > --- /dev/null > +++ b/miscutils/getrandom.c > @@ -0,0 +1,22 @@ > +#include > + > +#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ <= 24 > + > +#ifndef __NR_getrandom > +#include > +#endif > +#include > +#include "random.h" > + > +ssize_t getrandom(void *buffer, size_t length, unsigned int flags) > +{ > +#ifdef __NR_getrandom > + return syscall(__NR_getrandom, buffer, length, flags); > +#else > + /* For kernels that don't support getrandom() (< 3.17). */ > + errno = ENOSYS; > + return -1; > +#endif > +} > + > +#endif /* __GLIBC__ ... */ > diff --git a/miscutils/random.h b/miscutils/random.h > new file mode 100644 > index 000000000000..3131df5e8a5d > --- /dev/null > +++ b/miscutils/random.h > @@ -0,0 +1,19 @@ > +#ifndef _RANDOM_H > +#define _RANDOM_H 1 > + > +#include > +#include > + > +#ifndef GRND_NONBLOCK > +#define GRND_NONBLOCK 0x01 > +#endif > +#ifndef GRND_RANDOM > +#define GRND_RANDOM 0x02 > +#endif > +#ifndef GRND_INSECURE > +#define GRND_INSECURE 0x04 > +#endif > + > +ssize_t getrandom(void *buffer, size_t length, unsigned int flags); > + > +#endif /* _RANDOM_H */ > diff --git a/miscutils/seedrng.c b/miscutils/seedrng.c > index 967741dc72ea..8ce553e460b1 100644 > --- a/miscutils/seedrng.c > +++ b/miscutils/seedrng.c > @@ -29,7 +29,7 @@ > > //applet:IF_SEEDRNG(APPLET(seedrng, BB_DIR_USR_SBIN, BB_SUID_DROP)) > > -//kbuild:lib-$(CONFIG_SEEDRNG) += seedrng.o > +//kbuild:lib-$(CONFIG_SEEDRNG) += getrandom.o seedrng.o > > //usage:#define seedrng_trivial_usage > //usage: "[-d DIR] [-n]" > @@ -42,7 +42,11 @@ > #include "libbb.h" > > #include > +#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ <= 24 > +#include "random.h" > +#else > #include > +#endif > #include > > #ifndef GRND_INSECURE > -- > 2.34.1 > > From vda.linux at googlemail.com Mon Feb 27 12:15:59 2023 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 27 Feb 2023 13:15:59 +0100 Subject: [PATCH] fixdep: avoid underflow when end of entry doesn't coincide with EOF In-Reply-To: <20230221192030.3729279-1-arsen@gentoo.org> References: <20230221192030.3729279-1-arsen@gentoo.org> Message-ID: Applied, thank you. On Tue, Feb 21, 2023 at 8:24 PM Arsen Arsenovi? wrote: > > Bug: https://bugs.gentoo.org/893776 > Closes: https://bugs.busybox.net/show_bug.cgi?id=15326 > Signed-off-by: Arsen Arsenovi? > --- > Hi, > > This is a fix for the recently reported scandep-related build failure. > The linked Gentoo bug also includes a write-up explaining how the error > happens. > > Thanks in advance, have a lovely day. > > scripts/basic/fixdep.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c > index 426b4888b..66be73aad 100644 > --- a/scripts/basic/fixdep.c > +++ b/scripts/basic/fixdep.c > @@ -338,6 +338,11 @@ void parse_dep_file(void *map, size_t len) > do p--; while (!isalnum((unsigned char)*p)); > p++; > } > + if (p < m) { > + /* we've consumed the last filename of this list > + already. */ > + break; > + } > memcpy(s, m, p-m); s[p-m] = 0; > if (strrcmp(s, "include/autoconf.h") && > strrcmp(s, "arch/um/include/uml-config.h") && > -- > 2.39.2 > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://lists.busybox.net/mailman/listinfo/busybox From ben.busybox at backplane.be Tue Feb 28 22:17:19 2023 From: ben.busybox at backplane.be (ben.busybox at backplane.be) Date: Tue, 28 Feb 2023 23:17:19 +0100 Subject: sha256sum Illegal instruction on musl amd64 Message-ID: <8A57ED25-B681-4D2C-A8D8-67FD3F8C7955@backplane.be> Hi, I'm having an intermittent issue with "BusyBox v1.36.0 (2023-01-03 22:49:12 UTC)" (the one from the Docker image busybox:musl) when running on amd64 GitHub actions runner VMs (azure). When I use sha256sum it is getting terminated with SIGILL, Illegal instruction. The issue is hard to reproduce but I have a GitHub actions CI/CD job that I can re-run repeatedly (no changes to code, environment, data input, etc) that will occasionally have the issue. I managed to capture a core dump. / # file core-sha256sum.10.1677605036 core-sha256sum.10.1677605036: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 'sha256sum -w -s -c -', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/bin/sha256sum', platform: 'x86_64' # gdb /bin/sha256sum core-sha256sum.10.1677605036 Reading symbols from /bin/sha256sum... (No debugging symbols found in /bin/sha256sum) [New LWP 10] Core was generated by `sha256sum -w -s -c -'. Program terminated with signal SIGILL, Illegal instruction. #0 0x0000000000401161 in ?? () If I use "layout asm" it shows this: > 0?401161 or (%rax),%al Here's the result of an strace: 2023-02-28T21:24:48.2816253Z execve("/usr/bin/sha256sum", ["sha256sum", "-w", "-s", "-c", "-"], 0x7ffe64982460 /* 5 vars */) = 0 2023-02-28T21:24:48.2816600Z arch_prctl(ARCH_SET_FS, 0x51c258) = 0 2023-02-28T21:24:48.2816865Z set_tid_address(0x51cbd8) = 15 2023-02-28T21:24:48.2818368Z getuid() = 0 2023-02-28T21:24:48.2818764Z brk(NULL) = 0x1803000 2023-02-28T21:24:48.2819202Z brk(0x1805000) = 0x1805000 2023-02-28T21:24:48.2821626Z mmap(0x1803000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1803000 2023-02-28T21:24:48.2822306Z mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f54496bc000 2023-02-28T21:24:48.2822893Z read(0, "e4d5808efbd4239a2f496b6055ac15b2"..., 1024) = 154 2023-02-28T21:24:48.2823486Z mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f54496bb000 2023-02-28T21:24:48.2823993Z open("1.544MiB.bin", O_RDONLY|O_LARGEFILE) = 3 2023-02-28T21:24:48.2824623Z read(3, "\270\222\2W\262\203&^\1\304X\372\247H\6\261\212\220\303i0D\266tx\356\353\370\327\363\354q"..., 4096) = 4096 2023-02-28T21:24:48.2825392Z --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x401161} --- 2023-02-28T21:24:48.2826349Z +++ killed by SIGILL (core dumped) +++ 2023-02-28T21:24:48.2846595Z Illegal instruction Here's a later one with a simpler set of arguments: 2023-02-28T21:47:29.2574112Z + strace sha256sum 1.544MiB.bin 1MiB.bin 2023-02-28T21:47:29.2611500Z execve("/usr/bin/sha256sum", ["sha256sum", "1.544MiB.bin", "1MiB.bin"], 0x7ffc41e4baf0 /* 5 vars */) = 0 2023-02-28T21:47:29.2616858Z arch_prctl(ARCH_SET_FS, 0x51c258) = 0 2023-02-28T21:47:29.2617173Z set_tid_address(0x51cbd8) = 10 2023-02-28T21:47:29.2617428Z getuid() = 0 2023-02-28T21:47:29.2617682Z brk(NULL) = 0x1c4d000 2023-02-28T21:47:29.2623375Z brk(0x1c4f000) = 0x1c4f000 2023-02-28T21:47:29.2623919Z mmap(0x1c4d000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1c4d000 2023-02-28T21:47:29.2625076Z mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2a9de51000 2023-02-28T21:47:29.2625396Z open("1.544MiB.bin", O_RDONLY|O_LARGEFILE) = 3 2023-02-28T21:47:29.2625758Z read(3, "\270\222\2W\262\203&^\1\304X\372\247H\6\261\212\220\303i0D\266tx\356\353\370\327\363\354q"..., 4096) = 4096 2023-02-28T21:47:29.2626698Z --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x401161} --- 2023-02-28T21:47:29.2632505Z +++ killed by SIGILL (core dumped) +++ 2023-02-28T21:47:29.2632762Z Illegal instruction At the following URL the first run didn't fail but the second one did (I just hit rerun all jobs without changing anything else): https://github.com/backplane/avxtest/actions/runs/4297660126 (The name of that repo is based on my initial theory of the problem, but I don't see evidence that avx is involved.) You can bring up a shell with the core dump (and binary) in question using: docker run --rm -it --platform linux/amd64 ghcr.io/backplane/avxtest:1677620842 I use alpine to get strace and earlier gdb, file, etc. but I'm working with the binary from the busybox:musl container. Any idea what's going on? Thanks, Ben