Re: [PATCH] do not use gethostbyname() for hostname -s
On Monday 09 December 2013 22:56:34 you wrote: > 10.12.2013 01:40, Tito wrote: > > On Monday 09 December 2013 18:56:43 Michael Tokarev wrote: > >> There's no reason to call gethostbyname() on the value returned > >> by uname() when asked just for a short name of a host. This may > >> also be wrong, when uname is set to one value, but in /etc/hosts > >> (or elsewhere) the "canonical" name is different. This is often > >> the case for localhost entry in /etc/hosts: > >> > >> 127.0.0.1localhost myname > >> > >> With this content of /etc/hosts, and uname being set to myname, > >> busybox hostname -s will return localhost, while regular > >> hostname utility returns myname. > >> > >> Fix this by not calling gethostbyname() for the simple `hostname -s' > >> use. > [] > > Hi, > > I cannot reproduce the case you show with busybox hostname > > and /etc/hosts on debian 7: > > Interesting. Debian7 is exactly the system where I had issues with > original implementation: > > $ uname -n > gandalf > $ head -n1 /etc/hosts > 127.0.0.1localhost gandalf > $ hostname -s > gandalf > $ busybox hostname -s > localhost > $ cat /etc/debian_version > 7.2 > $ _ > > _My_ /etc/hosts actually has the first line like this: > > # list real hostname first localhost second or else busybox return wrong name > 127.0.0.1gandalf localhost > > and it is dated Sep-2010, so the comment should be from 2010 or before. > I changed it like shown above for this test. > > Today I discovered the same issue within a freshly installed debian system > in a virtual machine, the generated /etc/hosts had similar line > >127.0.0.1 localhost debian Hi, looks exatcly like mine. > > which resulted in busybox testsuite to fail (hostname-s-works failure due to > busybox returning localhost while system hostname returns debian). This > failure prompted me to try to fix this finally. Didn't use the testsuite, but results were different. The problem is confirmed by the other example. > The thing is that busybox hostname calls gethostbyname() on the > result of uname() call, while system hostname doesn't do this. But the patch > shows it too. > > > Even modifying /etc/hosts makes no difference: > > > > So now I'm wondering where "(or elsewhere)" could be? > > Well, I don't know what's wrong with our systems.. ;) > > > > BTW.: It is better if you attach patches as my or your email client > > ate the tabs and the patch doesn't apply cleanly. > > Almost always when someone sends patches as attachments, people > complain saying it is better to send patches inline. It really > is easier to reply to inline-patches adding comments to particular > place in the patch, and here I agree too - it is better to send > patches inline. I usually send both, inline for review and attached to preserve TABS etc. > My client can't ate tabs, -- it is more, I see the tabs in your > reply exactly as they were in my initial email. I used > /usr/sbin/sendmail directly to send my initial email ;) So the culprit is Kmail's copy and paste > I just tried saving the patch (whole my email) from thunderbird > to a temp file and applying it - it applies cleanly to both > 1.21 version and current git head. Patch utility strips CRs > when applying, but that's typical. > > Thanks, > > /mjt > Ciao, Tito ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] do not use gethostbyname() for hostname -s
10.12.2013 01:40, Tito wrote: > On Monday 09 December 2013 18:56:43 Michael Tokarev wrote: >> There's no reason to call gethostbyname() on the value returned >> by uname() when asked just for a short name of a host. This may >> also be wrong, when uname is set to one value, but in /etc/hosts >> (or elsewhere) the "canonical" name is different. This is often >> the case for localhost entry in /etc/hosts: >> >> 127.0.0.1 localhost myname >> >> With this content of /etc/hosts, and uname being set to myname, >> busybox hostname -s will return localhost, while regular >> hostname utility returns myname. >> >> Fix this by not calling gethostbyname() for the simple `hostname -s' >> use. [] > Hi, > I cannot reproduce the case you show with busybox hostname > and /etc/hosts on debian 7: Interesting. Debian7 is exactly the system where I had issues with original implementation: $ uname -n gandalf $ head -n1 /etc/hosts 127.0.0.1 localhost gandalf $ hostname -s gandalf $ busybox hostname -s localhost $ cat /etc/debian_version 7.2 $ _ _My_ /etc/hosts actually has the first line like this: # list real hostname first localhost second or else busybox return wrong name 127.0.0.1 gandalf localhost and it is dated Sep-2010, so the comment should be from 2010 or before. I changed it like shown above for this test. Today I discovered the same issue within a freshly installed debian system in a virtual machine, the generated /etc/hosts had similar line 127.0.0.1 localhost debian which resulted in busybox testsuite to fail (hostname-s-works failure due to busybox returning localhost while system hostname returns debian). This failure prompted me to try to fix this finally. The thing is that busybox hostname calls gethostbyname() on the result of uname() call, while system hostname doesn't do this. But the patch shows it too. > Even modifying /etc/hosts makes no difference: > So now I'm wondering where "(or elsewhere)" could be? Well, I don't know what's wrong with our systems.. ;) > BTW.: It is better if you attach patches as my or your email client > ate the tabs and the patch doesn't apply cleanly. Almost always when someone sends patches as attachments, people complain saying it is better to send patches inline. It really is easier to reply to inline-patches adding comments to particular place in the patch, and here I agree too - it is better to send patches inline. My client can't ate tabs, -- it is more, I see the tabs in your reply exactly as they were in my initial email. I used /usr/sbin/sendmail directly to send my initial email ;) I just tried saving the patch (whole my email) from thunderbird to a temp file and applying it - it applies cleanly to both 1.21 version and current git head. Patch utility strips CRs when applying, but that's typical. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] do not use gethostbyname() for hostname -s
On Monday 09 December 2013 18:56:43 Michael Tokarev wrote:
> There's no reason to call gethostbyname() on the value returned
> by uname() when asked just for a short name of a host. This may
> also be wrong, when uname is set to one value, but in /etc/hosts
> (or elsewhere) the "canonical" name is different. This is often
> the case for localhost entry in /etc/hosts:
>
> 127.0.0.1 localhost myname
>
> With this content of /etc/hosts, and uname being set to myname,
> busybox hostname -s will return localhost, while regular
> hostname utility returns myname.
>
> Fix this by not calling gethostbyname() for the simple `hostname -s'
> use.
>
> Signed-off-by: Michael Tokarev
>
> diff --git a/networking/hostname.c b/networking/hostname.c
> index d2516b5..1e68116 100644
> --- a/networking/hostname.c
> +++ b/networking/hostname.c
> @@ -106,12 +106,13 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
> OPT_i = 0x4,
> OPT_s = 0x8,
> OPT_F = 0x10,
> - OPT_dfis = 0xf,
> + OPT_dfi = 0x7,
> };
>
> unsigned opts;
> char *buf;
> char *hostname_str;
> + char *p;
>
> #if ENABLE_LONG_OPTS
> applet_long_options =
> @@ -134,10 +135,9 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
> if (applet_name[0] == 'd') /* dnsdomainname? */
> opts = OPT_d;
>
> - if (opts & OPT_dfis) {
> + if (opts & OPT_dfi) {
> /* Cases when we need full hostname (or its part) */
> struct hostent *hp;
> - char *p;
>
> hp = xgethostbyname(buf);
> p = strchrnul(hp->h_name, '.');
> @@ -159,6 +159,10 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
> bb_putchar('\n');
> }
> }
> + } else if (opts & OPT_s) {
> + p = strchrnul(buf, '.');
> + *p = '\0';
> + puts(buf);
> } else if (opts & OPT_F) {
> /* Set the hostname */
> do_sethostname(hostname_str, 1);
Hi,
I cannot reproduce the case you show with busybox hostname
and /etc/hosts on debian 7:
$ echo $HOSTNAME
debian
$ cat /etc/hostname
debian
$ cat /etc/hosts
127.0.0.1 localhost debian
$ hostname
debian
$ hostname -s
debian
$ ./busybox hostname
debian
$ ./busybox hostname -s
debian
Even modifying /etc/hosts makes no difference:
$ echo $HOSTNAME
debian
$ cat /etc/hostname
debian
$ cat /etc/hosts
127.0.0.1 localhost hosts.file.debian
$ hostname
debian
$ hostname -s
debian
$ ./busybox hostname
debian
$ ./busybox hostname -s
debian
So now I'm wondering where "(or elsewhere)" could be?
One interesting difference between busybox's hostname and
real hostname pops up if we change hostname on the fly:
su
hostname prova
debian:/home/tito# hostname
prova
debian:/home/tito# hostname -s
prova
debian:/home/tito# ./busybox hostname
prova
debian:/home/tito# ./busybox hostname -s
hostname: prova: Unknown host
This in fact is fixed by your patch:
debian:~/Desktop/SourceCode/busybox$ ./busybox hostname
prova
debian:~/Desktop/SourceCode/busybox$ ./busybox hostname -s
prova
BTW.: It is better if you attach patches as my or your email client
ate the tabs and the patch doesn't apply cleanly.
Ciao,
Tito
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] do not use gethostbyname() for hostname -s
There's no reason to call gethostbyname() on the value returned
by uname() when asked just for a short name of a host. This may
also be wrong, when uname is set to one value, but in /etc/hosts
(or elsewhere) the "canonical" name is different. This is often
the case for localhost entry in /etc/hosts:
127.0.0.1 localhost myname
With this content of /etc/hosts, and uname being set to myname,
busybox hostname -s will return localhost, while regular
hostname utility returns myname.
Fix this by not calling gethostbyname() for the simple `hostname -s'
use.
Signed-off-by: Michael Tokarev
diff --git a/networking/hostname.c b/networking/hostname.c
index d2516b5..1e68116 100644
--- a/networking/hostname.c
+++ b/networking/hostname.c
@@ -106,12 +106,13 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
OPT_i = 0x4,
OPT_s = 0x8,
OPT_F = 0x10,
- OPT_dfis = 0xf,
+ OPT_dfi = 0x7,
};
unsigned opts;
char *buf;
char *hostname_str;
+ char *p;
#if ENABLE_LONG_OPTS
applet_long_options =
@@ -134,10 +135,9 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
if (applet_name[0] == 'd') /* dnsdomainname? */
opts = OPT_d;
- if (opts & OPT_dfis) {
+ if (opts & OPT_dfi) {
/* Cases when we need full hostname (or its part) */
struct hostent *hp;
- char *p;
hp = xgethostbyname(buf);
p = strchrnul(hp->h_name, '.');
@@ -159,6 +159,10 @@ int hostname_main(int argc UNUSED_PARAM, char **argv)
bb_putchar('\n');
}
}
+ } else if (opts & OPT_s) {
+ p = strchrnul(buf, '.');
+ *p = '\0';
+ puts(buf);
} else if (opts & OPT_F) {
/* Set the hostname */
do_sethostname(hostname_str, 1);
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
mdev - add selinux support
Hello,
Attached patch adds basic selinux support to mdev in what I think is
most efficient way. It relabels file not caring if it was just created
or existed before (for example devtmpfs mount).
Amadeusz Sławiński
diff -uNr a/util-linux/mdev.c b/util-linux/mdev.c
--- a/util-linux/mdev.c 2013-12-07 14:47:24.122978065 +0100
+++ b/util-linux/mdev.c 2013-12-07 14:47:51.875977453 +0100
@@ -776,6 +776,19 @@
}
if (mknod(node_name, rule->mode | type, makedev(major, minor)) && errno != EEXIST)
bb_perror_msg("can't create '%s'", node_name);
+
+#if ENABLE_SELINUX
+ /* relabel file, don't care if it existed before or was just created */
+ if (is_selinux_enabled()) {
+security_context_t scontext = NULL;
+char *node_path = xasprintf("/dev/%s", node_name);
+
+if (matchpathcon(node_path, rule->mode | type, &scontext) == 0)
+ setfilecon(node_path, scontext);
+freecon(scontext);
+ }
+#endif
+
if (ENABLE_FEATURE_MDEV_CONF) {
chmod(node_name, rule->mode);
chown(node_name, rule->ugid.uid, rule->ugid.gid);
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox testsuite on non-linux
09.12.2013 17:51, Michael Tokarev пишет: Forgot to comment on this: > tar symlinks mode (both kfreebsd and hurd) > --- expected > +++ actual > @@ -1,9 +1,9 @@ > input_dir/input_file > -input_dir/input_soft -> input_file > +input_dir/input_soft -> input_dir/input_file > input_file -> input_dir/input_file > -input_soft -> input_dir/input_soft > +input_soft -> input_file > Ok: 0 > -rwxrx input_dir/input_file > -lrwxrwxrwx input_file > +-rwxrx input_dir/input_soft > -rwxrx input_file > -lrwxrwxrwx input_file > +lrwxr-xr-x input_file On both kfreebsd and hurd, ln directory/ performs the linking of the _target_ of the symlink, not the symlink itself. So while in this test, we expect input_dir/input_soft to be a symlink (hardlinked with input_soft), it actually is a hardlink with input_file. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
busybox testsuite on non-linux
Hello. Here are a few tests from the testsuite which fails on debian-hurd and debian-kfreebsd. awk handles non-existing file correctly on hurd ENOENT is 0x4002, the test expects 2. It is not portable to expect certain errno values. Different OSes may use different values for the same error, that's what is for. I'm not sure what this test should be testing. 2 possible solutions: 1) test for ERRNO!=0 instead of ERRNO itself, or 2) print value of ENOENT using a tiny C program and compare with that. pidof this does not print its own pid on hurd or freebsd testing "pidof this" "pidof pidof.tests | grep -o -w $$" "$$\n" "" "" most likely the process is named 'sh pidof.tests', not pidof.tests This test fails on both kfreebsd and hurd systems - it does not print its own pid, `pidof pidof.tests' prints nothig. tar symlinks mode (both kfreebsd and hurd) --- expected +++ actual @@ -1,9 +1,9 @@ input_dir/input_file -input_dir/input_soft -> input_file +input_dir/input_soft -> input_dir/input_file input_file -> input_dir/input_file -input_soft -> input_dir/input_soft +input_soft -> input_file Ok: 0 -rwxrx input_dir/input_file -lrwxrwxrwx input_file +-rwxrx input_dir/input_soft -rwxrx input_file -lrwxrwxrwx input_file +lrwxr-xr-x input_file kfreebsd: group on files is inherited from parent dir. cpio tests fail. FAIL: cpio extracts zero-sized hardlinks --- expected +++ actual @@ -1,4 +1,4 @@ 1 blocks 0 --rw-r--r-- 2 2952 1009 0 x --rw-r--r-- 2 2952 1009 0 y +-rw-r--r-- 2 2952 112 0 x +-rw-r--r-- 2 2952 112 0 y Mabe remove (using sed, in $FILTER_LS) the group column for testing? Note the same may happen on linux too, depending on the filesystem in use and even filesystem mount options (-o grpid or -o bsdgroups for a few linux filesystems). du tests fail on kfreebsd filesystems: du-k-works 16+64Kb files in a dir, `du -k .' is expected to be one of 80, 84 or 88, actual is 82. du-l-works - same issue, result expected to be 144, 148, 152 or 156, actual is 146 I'm not sure why these sizes are multiple of 4Kb. As you can see, on a bsd system the directory size is different. Maybe any number between, say, 80 and 88 should be ok? That's all for now, but I haven't enabled all applets. Thanks, /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] expand: use printable_string instead of hard-coding implementation
That meant to be unicode_strwidth() not printable_string(). Typo in the subject. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] expand: use printable_string instead of hard-coding implementation
Signed-off-by: Michael Tokarev
diff --git a/coreutils/expand.c b/coreutils/expand.c
index 25bbffc..8d376ff 100644
--- a/coreutils/expand.c
+++ b/coreutils/expand.c
@@ -78,11 +78,7 @@ static void expand(FILE *file, unsigned tab_size, unsigned
opt)
unsigned len;
*ptr = '\0';
# if ENABLE_UNICODE_SUPPORT
- {
- uni_stat_t uni_stat;
- printable_string(&uni_stat, ptr_strbeg);
- len = uni_stat.unicode_width;
- }
+ len = unicode_strwidth(ptr_strbeg);
# else
len = ptr - ptr_strbeg;
# endif
@@ -138,12 +134,9 @@ static void unexpand(FILE *file, unsigned tab_size,
unsigned opt)
printf("%*s%.*s", len, "", n, ptr);
# if ENABLE_UNICODE_SUPPORT
{
- char c;
- uni_stat_t uni_stat;
- c = ptr[n];
+ char c = ptr[n];
ptr[n] = '\0';
- printable_string(&uni_stat, ptr);
- len = uni_stat.unicode_width;
+ len = unicode_strwidth(ptr);
ptr[n] = c;
}
# else
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] do not fail build if MAXSYMLINKS isn't defined
This is needed for, eg, hurd, which is known to have no constraints. Signed-off-by: Michael Tokarev diff --git a/libbb/xreadlink.c b/libbb/xreadlink.c index ec95af2..a610de8 100644 --- a/libbb/xreadlink.c +++ b/libbb/xreadlink.c @@ -8,6 +8,12 @@ #include "libbb.h" +/* some systems (eg Hurd) does not have MAXSYMLINKS definition, + * set it to some reasonable value if it isn't defined */ +#ifndef MAXSYMLINKS +# define MAXSYMLINKS 20 +#endif + /* * NOTE: This function returns a malloced char* that you will have to free * yourself. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
