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
