bug#7317: Bug in SLEEP command
Hello guys! I found a bug in 'sleep' command. Please see below: # date Tue Oct 5 14:12:11 EEST 2010 [r...@gate ~]# sleep 36500d ; date Sat Oct 30 10:38:44 EEST 2010 [r...@gate ~]# As you can see - 'sleep' was terminated by himself after 24 days, 20 hours, 26 minutes and 33 seconds. 24*24*3600 + 20*3600 + 26*60 + 33 = 2073600 + 72000 + 1560 + 33 = 2147193 seconds It seems like overflow. coreutils 6.10-6 Debian 5.0.6 -- A.P.
bug#7313: sha1sum etc, output in base64
On 02/11/10 13:16, Caleb Cushing wrote: I'd like to be able to do something like this sha1sum --base64 and instead of getting a hex representation get a base64 representation. An alternative might be sha1sum --raw | base64 obviously this applies to md5sum, sha512sum, etc This is one of those border line cases. I'm 40:60 against adding it as it seems easy enough to acheive using existing tools: env printf $(sha1sum file | sed 's/ .*//; s/\(..\)/\\x\1/g') | base64 Note using env above is to bypass the inbuilt printf which doesn't support \x on dash for example. cheers, Pádraig.
bug#7317: Bug in SLEEP command
On 11/02/2010 09:46 AM, Андрей Передрий wrote: Hello guys! I found a bug in 'sleep' command. As you can see - 'sleep' was terminated by himself after 24 days, 20 hours, 26 minutes and 33 seconds. 24*24*3600 + 20*3600 + 26*60 + 33 = 2073600 + 72000 + 1560 + 33 = 2147193 seconds It seems like overflow. coreutils 6.10-6 Debian 5.0.6 Is your system 32-bit or 64-bit? It makes a difference in determining whether there is a bug in the OS sleep primitives (for example, we know that 64-bit Linux has a bug where nanosleep with an extremely large value will cause the kernel to overflow and sleep for the wrong amount of time, but coreutils has workarounds in place for that). Also, consider upgrading; the latest stable coreutils release is 8.6, and there have been some gnulib fixes in the meantime to improve the robustness of the sleep workarounds in use by coreutils. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#7317: Bug in SLEEP command
On 02/11/10 15:46, Андрей Передрий wrote:
Hello guys!
I found a bug in 'sleep' command.
Please see below:
# date
Tue Oct 5 14:12:11 EEST 2010
[r...@gate ~]# sleep 36500d ; date
Sat Oct 30 10:38:44 EEST 2010
[r...@gate ~]#
As you can see - 'sleep' was terminated by himself after 24 days, 20 hours,
26 minutes and 33 seconds.
24*24*3600 + 20*3600 + 26*60 + 33 = 2073600 + 72000 + 1560 + 33 = 2147193
seconds
It seems like overflow.
coreutils 6.10-6
Debian 5.0.6
eek!
That's lenny right, with kernel 2.6.32 or so.
POSIX says that we should support 2147483647 seconds at least.
We could make multiple calls to xnanosleep if the param is
greater than that, but do we really need to support 68 years.
Currently we silently truncate to this limit.
Anyway could you send the output of: strace sleep 36500d
On 64 bit lenny here I get: nanosleep({315360, 0},
On 32 bit Fedora 11 I get: nanosleep({2147483647, 9}
If you get a large value being passed down,
then it suggests an issue with glibc/kernel?
cheers,
P?draig.
uname -a
Linux * 2.6.9-89.0.23.ELsmp #1 SMP Wed Mar 17 06:55:21 EDT 2010
i686 athlon i386 GNU/Linux
cat /etc/redhat-release
CentOS release 4.8 (Final)
--
A.P.
bug#7313: sha1sum etc, output in base64
On 02/11/10 16:20, Pádraig Brady wrote: env printf $(sha1sum file | sed 's/ .*//; s/\(..\)/\\x\1/g') | base64 I just dug out an old script of mine that did low level manipulations like this, and I had used: openssl dgst -sha1 -binary $file | openssl enc -base64 While that does show there is a need for this, it also shows there are widely available tools to do it already. cheers, Pádraig.
bug#7317: Bug in SLEEP command
Hello guys!
I found a bug in 'sleep' command.
As you can see - 'sleep' was terminated by himself after 24 days, 20 hours,
26 minutes and 33 seconds.
24*24*3600 + 20*3600 + 26*60 + 33 = 2073600 + 72000 + 1560 + 33 = 2147193
seconds
It seems like overflow.
coreutils 6.10-6
Debian 5.0.6
Is your system 32-bit or 64-bit? It makes a difference in determining
whether there is a bug in the OS sleep primitives (for example, we know
that 64-bit Linux has a bug where nanosleep with an extremely large
value will cause the kernel to overflow and sleep for the wrong amount
of time, but coreutils has workarounds in place for that).
Also, consider upgrading; the latest stable coreutils release is 8.6,
and there have been some gnulib fixes in the meantime to improve the
robustness of the sleep workarounds in use by coreutils.
I am sorry!
Correct platform is:
RHEL Centos 4.6 4.8
2.6.9-89.0.23.ELsmp
strace sleep 36500d
execve(/bin/sleep, [sleep, 36500d], [/* 20 vars */]) = 0
uname({sys=Linux, node=gate.shipregistr.kiev.ua, ...}) = 0
brk(0) = 0x9541000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=20328, ...}) = 0
old_mmap(NULL, 20328, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f56000
close(3)= 0
open(/lib/tls/libm.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0003\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=212236, ...}) = 0
old_mmap(NULL, 139424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x54d000
old_mmap(0x56e000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x56e000
close(3)= 0
open(/lib/tls/librt.so.1, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320 \0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=48788, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f55000
old_mmap(NULL, 81656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x28b000
old_mmap(0x293000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x293000
old_mmap(0x295000, 40696, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x295000
close(3)= 0
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200O\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1544948, ...}) = 0
old_mmap(NULL, 1244380, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x111000
old_mmap(0x23b000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x129000) = 0x23b000
old_mmap(0x23f000, 7388, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x23f000
close(3)= 0
open(/lib/tls/libpthread.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0PH\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=105912, ...}) = 0
old_mmap(NULL, 70108, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x65
old_mmap(0x65e000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x65e000
old_mmap(0x66, 4572, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x66
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f54000
mprotect(0x65e000, 4096, PROT_READ) = 0
mprotect(0x23b000, 8192, PROT_READ) = 0
mprotect(0x293000, 4096, PROT_READ) = 0
mprotect(0x56e000, 4096, PROT_READ) = 0
mprotect(0xfbe000, 4096, PROT_READ) = 0
set_thread_area({entry_number:-1 - 6, base_addr:0xb7f546c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0xb7f56000, 20328) = 0
set_tid_address(0xb7f54708) = 19936
rt_sigaction(SIGRTMIN, {0x654380, [], SA_RESTORER|SA_SIGINFO, 0x65bc90}, NULL,
8) = 0
rt_sigaction(SIGRT_1, {0x6543f0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO,
0x65bc90}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfe5e27c, 35, (nil), 0}) = 0
brk(0) = 0x9541000
brk(0x9562000) = 0x9562000
clock_gettime(CLOCK_REALTIME, {1288719488, 927427000}) = 0
nanosleep({2147483647, 9},
--
A.P.
bug#7317: Bug in SLEEP command
On 02/11/10 16:41, Eric Blake wrote: On 11/02/2010 09:46 AM, Андрей Передрий wrote: Hello guys! I found a bug in 'sleep' command. As you can see - 'sleep' was terminated by himself after 24 days, 20 hours, 26 minutes and 33 seconds. 24*24*3600 + 20*3600 + 26*60 + 33 = 2073600 + 72000 + 1560 + 33 = 2147193 seconds It seems like overflow. coreutils 6.10-6 Debian 5.0.6 Is your system 32-bit or 64-bit? It makes a difference in determining whether there is a bug in the OS sleep primitives (for example, we know that 64-bit Linux has a bug where nanosleep with an extremely large value will cause the kernel to overflow and sleep for the wrong amount of time, but coreutils has workarounds in place for that). I had a quick look at the gnulib replacement which seems to assume 49 days is the worst case, whereas we now need to use 24 days? cheers, Pádraig.
bug#7320: 'group' command gives wrong/extra group
Hi, It appears that the 'groups' command doesn't get the list of groups for a currently-running process quite right. The conditions I tested were where the UID and EUID of the process were different, and the GID and EGID were both set to the primary group of the EUID. The groups command looked up the real user and added the primary group from /etc/passwd to the list of groups the user was in, even though the process had no permissions for this extra group. So, for example say /etc/passwd has at least these 2 entries: root:x:0:0:root:/root:/bin/sh user:x:1000:1000:user:/home/user:/bin/sh and /etc/group has at least these 3 entries: root:x:0: other:x:500: user:x:1000: If a process as UID=0, EUID=1000, GID=1000, and EGID=1000 and no supplemental groups, the correct list of groups should be user but the groups command shows user root If the passwd file is changed like so: root:x:0:500:root:/root:/bin/sh then the output of groups is user other --- Tested on Debian Slink groups (GNU coreutils) 8.5 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie and James Youngman. -- Brynnen Owen( this space for rent ) o...@illinois.edu ( )
