Re: Ash glob symlink regression when using libc glob
On Mon, 30 Oct 2017 20:24:08 +0100 Denys Vlasenko wrote: > On Sun, Oct 29, 2017 at 7:43 PM, Lauri Kasanen wrote: > > Hi, > > > > It was reported the following case fails with bb 1.27.2: > > > > ln -s nonexistent mylink > > mv myli* someother > > > > It also fails with master. I bisected it to > > b3f29b452a660a7293162897424bed205f7f9147, "ash: use glob() from libc". > > Works with bash. > > Can't reproduce. myli* does expend for me. It fails with glibc 2.24 and 2.7, x86 and x86_64, so probably everything between. Are you on a more recent glibc? My attached config was from the bisect commit, so applying it directly to master may cause the wrong value for CONFIG_ASH_INTERNAL_GLOB. - Lauri ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash glob symlink regression when using libc glob
On Tue, Oct 31, 2017 at 8:31 AM, Lauri Kasanen wrote: > On Mon, 30 Oct 2017 20:24:08 +0100 > Denys Vlasenko wrote: > >> On Sun, Oct 29, 2017 at 7:43 PM, Lauri Kasanen wrote: >> > Hi, >> > >> > It was reported the following case fails with bb 1.27.2: >> > >> > ln -s nonexistent mylink >> > mv myli* someother >> > >> > It also fails with master. I bisected it to >> > b3f29b452a660a7293162897424bed205f7f9147, "ash: use glob() from libc". >> > Works with bash. >> >> Can't reproduce. myli* does expend for me. > > It fails with glibc 2.24 and 2.7, x86 and x86_64, so probably everything > between. Are you on a more recent glibc? $ /lib64/libc.so.6 GNU C Library (GNU libc) development release version 2.26.9000. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash glob symlink regression when using libc glob
On Tue, 31 Oct 2017 13:34:48 +0100 Denys Vlasenko wrote: > > It fails with glibc 2.24 and 2.7, x86 and x86_64, so probably everything > > between. Are you on a more recent glibc? > > $ /lib64/libc.so.6 > GNU C Library (GNU libc) development release version 2.26.9000. This looks relevant: http://sourceware.org/git/?p=glibc.git;a=commit;h=5554304f0dddf75dc27cc6250fc53355161fd16a So it was fixed after 2.26 and no released glibc contains the fix. How about either editing the description to say glibc >= 2.27 only, or even checking that compile-time? - Lauri ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash glob symlink regression when using libc glob
On Tue, Oct 31, 2017 at 8:48 PM, Lauri Kasanen wrote: > > So it was fixed after 2.26 and no released glibc contains the fix. How > about either editing the description to say glibc >= 2.27 only, or even > checking that compile-time? I would like to have both. And probably give a preprocessor warning about this, something like "warning: glibc <2.27 has buggy glob(); enabling ash internal one" ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 6/7] grep: Skip grepping symlinks to directories
Applied, thanks On Sat, Oct 7, 2017 at 7:53 PM, James Clarke wrote: > When grep is passed -r, recursive_action will treat any symlinks to > directories not in the root as normal files, since it lstat's them and > is therefore told they are not directories. However, file_action_grep > will still try to fopen and read from them to see whether they match, > which varies in behaviour across platforms. Linux will give EISDIR and > thus grep will not find any matching lines, but FreeBSD will give the > raw contents of the directory itself, which may match the given pattern. > Also, if grep is passed -c, it will even print a count for these > symlinks, even on Linux. > > Since this recursive_action behaviour is required for the correct > functioning of other applets, such as tar, grep should handle this > special case and skip any such symlinks. > > Signed-off-by: James Clarke > --- > findutils/grep.c | 22 -- > 1 file changed, 20 insertions(+), 2 deletions(-) > > diff --git a/findutils/grep.c b/findutils/grep.c > index f72175afb..0cb0aac64 100644 > --- a/findutils/grep.c > +++ b/findutils/grep.c > @@ -639,11 +639,29 @@ static void load_regexes_from_file(llist_t *fopt) > } > > static int FAST_FUNC file_action_grep(const char *filename, > - struct stat *statbuf UNUSED_PARAM, > + struct stat *statbuf, > void* matched, > int depth UNUSED_PARAM) > { > - FILE *file = fopen_for_read(filename); > + FILE *file; > + struct stat statbufFollow; > + > + /* If we are given a link to a directory, we should bail out now, > rather > +* than trying to open the "file" and hoping getline gives us nothing, > +* since that is not portable across operating systems (FreeBSD for > example > +* will return the raw directory contents). */ > + if (S_ISLNK(statbuf->st_mode)) { > + if (stat(filename, &statbufFollow) < 0) { > + if (!SUPPRESS_ERR_MSGS) > + bb_simple_perror_msg(filename); > + return 0; > + } > + > + if (S_ISDIR(statbufFollow.st_mode)) > + return 1; > + } > + > + file = fopen_for_read(filename); > if (file == NULL) { > if (!SUPPRESS_ERR_MSGS) > bb_simple_perror_msg(filename); > -- > 2.14.1 > > ___ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 7/7] libbb.h: Handle missing HOST_NAME_MAX; ensure MAXFOOLEN agrees with FOO_MAX
How about this? --- a/networking/traceroute.c +++ b/networking/traceroute.c @@ -709,6 +709,9 @@ packet_ok(int read_len, len_and_sockaddr *from_lsa, # if ENABLE_FEATURE_TRACEROUTE_VERBOSE if (verbose) { +# ifndef MAXHOSTNAMELEN +# define MAXHOSTNAMELEN 80 +# endif unsigned char *p; char pa1[MAXHOSTNAMELEN]; char pa2[MAXHOSTNAMELEN]; diff --git a/util-linux/fdisk_osf.c b/util-linux/fdisk_osf.c index 1141b78..1328c1f 100644 --- a/util-linux/fdisk_osf.c +++ b/util-linux/fdisk_osf.c @@ -709,6 +709,9 @@ sync_disks(void) static void xbsd_write_bootstrap(void) { +#ifndef MAXPATHLEN +# define MAXPATHLEN 1024 +#endif char path[MAXPATHLEN]; const char *bootdir = BSD_LINUX_BOOTDIR; const char *dkbasename; ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 7/7] libbb.h: Handle missing HOST_NAME_MAX; ensure MAXFOOLEN agrees with FOO_MAX
On 31 Oct 2017, at 15:06, Denys Vlasenko wrote: > > How about this? > > --- a/networking/traceroute.c > +++ b/networking/traceroute.c > @@ -709,6 +709,9 @@ packet_ok(int read_len, len_and_sockaddr *from_lsa, > > # if ENABLE_FEATURE_TRACEROUTE_VERBOSE >if (verbose) { > +# ifndef MAXHOSTNAMELEN > +# define MAXHOSTNAMELEN 80 > +# endif 80 is definitely not the right fallback value to use. As mentioned by Kang-Che earlier in the thread, 255 is the POSIX defined minimum[0] for HOST_NAME_MAX. In fact, it should really be using INET6_ADDRSTRLEN here since it's just being used as the destination for inet_ntop with AF_INET6, and this has to be defined in , though the spec says it must be 46 so we could just use that as a fallback if it isn't even defined.[1] >unsigned char *p; >char pa1[MAXHOSTNAMELEN]; >char pa2[MAXHOSTNAMELEN]; > diff --git a/util-linux/fdisk_osf.c b/util-linux/fdisk_osf.c > index 1141b78..1328c1f 100644 > --- a/util-linux/fdisk_osf.c > +++ b/util-linux/fdisk_osf.c > @@ -709,6 +709,9 @@ sync_disks(void) > static void > xbsd_write_bootstrap(void) > { > +#ifndef MAXPATHLEN > +# define MAXPATHLEN 1024 > +#endif This is linux-specific, which has MAXPATHLEN, so there's no point doing this. >char path[MAXPATHLEN]; >const char *bootdir = BSD_LINUX_BOOTDIR; >const char *dkbasename; Regards, James [0] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html [1] http://pubs.opengroup.org/onlinepubs/95399/basedefs/netinet/in.h.html ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
NOEXEC environment bug
I believe I have found a bug in the current version of busybox. When: * an applet is marked NOEXEC, * busybox is configured with CONFIG_FEATURE_SH_STANDALONE=y, and * busybox's ash is asked to do "ENV_VAR=newval no_exec_app" Then the no_exec app is not called with the new environment. This affects git master d5c1482fbac71c51e3add52632cdf1f9f9e6661b and 1:1.21.0-1ubuntu1 To reproduce from git (on linux): git pull make defconfig sed -i 's/# CONFIG_FEATURE_SH_STANDALONE is not set/CONFIG_FEATURE_SH_STANDALONE=y/' .config make ./busybox ash -c 'BUG=1 head /proc/self/environ | grep -q BUG && echo ok || echo bug' ./busybox ash -c 'BUG=1 ./busybox head /proc/self/environ | grep -q BUG && echo ok || echo bug' The first echoes "bug" because the environment is not set. The second bypasses the NOEXEC and reports "ok" because the environment is set. If CONFIG_FEATURE_SH_STANDALONE is not set, then both echo "ok". The bug is also in the ubuntu version of busybox (so its not a recent change). $ docker run --rm busybox:1-ubuntu sh -c \ 'BUG=1 head /proc/self/environ | grep -q BUG && echo ok || echo bug' bug $ docker run --rm busybox:1-ubuntu sh -c \ 'BUG=1 /bin/head /proc/self/environ | grep -q BUG && echo ok || echo bug' ok Alpine linux uses a similar command to check if /proc is really mounted, or is just a semi-convincing fake. With CONFIG_FEATURE_SH_STANDALONE, real /proc registers as a fake. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] inetd as unprivileged user
When I tried to use inetd as an unprivileged user on linux (4.9.x, x86_64, glibc or musl), I get: inetd: can't set groups: Operation not permitted I believe the problem is line 1486, where it compares the desired uid to 0, rather than to the current uid, to decide whether to set groups. For example: printf '127.0.0.1:3030 stream tcp nowait jack ./echo.sh' > inetd.conf printf '#!/bin/sh\necho ok\nsleep 1' > echo.sh chmod 755 echo.sh ./busybox inetd -e -f inetd.conf & nc 127.0.0.1 3030 With the patch, it echoes "ok". Without the patch, inetd gives an error: inetd: can't set groups: Operation not permitted Of course, to placate line 1486 one could use: printf '127.0.0.1:3030 stream tcp nowait root ./echo.sh' > inetd.conf but this results in the earlier error: inetd: non-root must run services as himself inetd-setgroups-fix.diff Description: Binary data ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox