Bug#567945: lsh-server: Does not configure on mipsel
Magnus Holmgren holmg...@debian.org writes: Starting secure shell v2 server: lshdClosed spurious fd 3 I also think this message is suspicious. lshd tries to close all fd:s between 3 and getdtablesize() (to avoid that any spurious open fd leaks to user processes it spawns). Expected result is that all these close calls should fail with EBADF. So what is fd 3, and why is it open? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514917: libc6-dev: CMSG_NXTHDR can't be used to construct new control messages, due to its payload length validation
Package: libc6-dev
Version: 2.7-18
Severity: normal
The macros CMSG_FIRSTHDR and CMSG_NXTHDR (defined in in
/usr/include/bits/bits/socket.h) use inconsistent validation of the
length of the next control message.
CMSG_FIRSTHDR just checks that the msg_controllen is large enough for
a cmsghdr to fit. CMSG_NXTHDR also checks that the *payload* of the cmsg
fits. Compare
#define CMSG_FIRSTHDR(mhdr) \
((size_t) (mhdr)-msg_controllen = sizeof (struct cmsghdr) \
? (struct cmsghdr *) (mhdr)-msg_control : (struct cmsghdr *) NULL)
to
#define CMSG_NXTHDR(mhdr, cmsg) __cmsg_nxthdr (mhdr, cmsg)
_EXTERN_INLINE struct cmsghdr *
__NTH (__cmsg_nxthdr (struct msghdr *__mhdr, struct cmsghdr *__cmsg))
{
if ((size_t) __cmsg-cmsg_len sizeof (struct cmsghdr))
/* The kernel header does this so there may be a reason. */
return 0;
__cmsg = (struct cmsghdr *) ((unsigned char *) __cmsg
+ CMSG_ALIGN (__cmsg-cmsg_len));
if ((unsigned char *) (__cmsg + 1) ((unsigned char *) __mhdr-msg_control
+ __mhdr-msg_controllen)
- || ((unsigned char *) __cmsg + CMSG_ALIGN (__cmsg-cmsg_len)
((unsigned char *) __mhdr-msg_control + __mhdr-msg_controllen)))
/* No more entries. */
return 0;
return __cmsg;
}
When parsing a msghdr from recvmsg, it makes sense to check that the
payload length fits, and return NULL if the messages appears to be
truncated. From this point of view, it would make sense to add a
similar check to CMSG_FIRSTHDR.
However, when preparing a msghdr for sendmsg, consisting of several
control messages, this length check makes these macros almost
unusable. Consider code like
struct msghdr hdr;
struct cmsghdr *cmsg;
[...]
hdr.msg_controllen = CMSG_SPACE(sizeof(struct ucred)) +
CMSG_SPACE(sizeof(int));
hdr.msg_control = alloca(hdr.msg_controllen);
cmsg = CMSG_FIRSTHDR(hdr);
[...]
cmsg-cmsg_len = CMSG_LEN(sizeof(struct ucred));
cmsg = CMSG_NXTHDR(hdr, cmsg);
[...]
cmsg-cmsg_len = CMSG_LEN(sizeof(int));
As far as I understand, this is the proper way to fill out a msghdr
structure with two control messages. However, the call to CMSG_NXTHDR
implies a length check that accesses __cmsg-cmsg_len (line marked -
in the definition). This field is not yet initialized, and if it
happens to contain a large value, CMSG_NXTHDR returns NULL, not the
address of the space allocated for the second control message. So then
the second control message, which I carefully allocated space for,
can't be filled out.
CMSG_FIRSTHDR does not check the cmsg_len field of the first control
message, and this is documented in the sense that the example code for
sending an array of fds in the linux cmsg(3) man page (as well as BSD
manpages) depends on this behavior: If CMSG_FIRSTHDR used a stricter
check as in CMSG_NXTHDR, then this example code would fail in exactly
the same way as my example, due to an access of an initialized
cmsg_len field. So why should CMSG_NXTHDR use a stricter length check?
I don't know how other C libraries do this, or what relevant standards
say. The easiest fix is to just remove the check from CMSG_NXTHDR.
As a workaround, I think I could memset the entire control area to
zero, so that all length fields are zero, no matter where they're
actually located when the control message is layed out, but that still
leaves CMSG_FIRSTHDR and CMSG_NXTHDR with inconsistent behavior.
To me it would make more sense to have separate macros for reading and
writing:
CMSG_FIRSTHDR(mhdr)
CMSG_NXTHDR(mhdr, cmsg)
could check the length, and would be used for processing msghdr from
recvmesg. Then have two new macros,
CMSG_PUT_FIRSTHDR(mhdr, len)
CMSG_PUT_NXTHDR(mhdr, cmsg, len)
that takes the length of the next control message as an additional
argument, uses that to check that the control message fits within
msg_controllen, and they can also initialize cmsg_len while they're at
it. But maybe such an API change is totally unrealistic.
Regards,
/Niels Möller
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=sv_SE.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6-dev depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii linux-libc-dev2.6.26-13 Linux support headers for userspac
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler
ii gcc-2.95 [c-compiler]1:2.95.4-27 The GNU C compiler
ii gcc-3.0 [c-compiler] 1:3.0.4-7 The GNU C compiler.
ii gcc-3.2 [c-compiler] 1:3.2.3-9 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-15 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-25The GNU C compiler
ii gcc-4.3
Bug#507597: ratpoison not using ~/.ratpoisonrc
Bernhard R. Link brl...@debian.org writes: That is normal, as ratpoison got the key, it has to fake a key-press and xterm is ignoring keys not directly from the X server by default. (try enabling Allow SendEvent in xterm, then it should get this key). I realized that, a short while after filing the bugreport. I'm not able to reproduce this. Using a .ratpoisonrc like that seems to work fine here (well, section needs shift and onehalf needs altgr, so it is quite hard to use, but it works using 1.4.3-1) [...] I'm out of ideas here. Only difference in my setting is that my X server is not lenny's but a remote one. But I hope that should not make any difference... Any suggestions on how I can help debug it? I'm also very puzzled, since the same commands work fine from the command line (ratpoison -c '...'). For example, is there any easy (besides looking at the i/o with strace) to log the communication between ratpoison and the X-server? My X-server, according to xdpyinfo: name of display::0.0 version number:11.0 vendor string:The X.Org Foundation vendor release number:10402000 X.Org version: 1.4.2 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 [...] I'm not very familar with xorg or debian's packaging thereof, but the packages I have installed are: $ dpkg -l 'xserver*' |grep '^ii' ii xserver-xfree861:7.1.0-19 transitional package for moving from XFree86 ii xserver-xorg 1:7.3+18 the X.Org X server ii xserver-xorg-core 2:1.4.2-10Xorg X server - core server ii xserver-xorg-input-all 1:7.3+18 the X.Org X server -- input driver metapacka ii xserver-xorg-input-evdev 1:2.0.8-1 X.Org X server -- evdev input driver ii xserver-xorg-input-kbd 1:1.3.1-1 X.Org X server -- keyboard input driver ii xserver-xorg-input-mouse 1:1.3.0-1 X.Org X server -- mouse input driver ii xserver-xorg-input-synaptics 0.14.7~git20070706-3 Synaptics TouchPad driver for X.Org/XFree86 ii xserver-xorg-input-wacom 0.7.9.3-2 X.Org X server -- Wacom input driver ii xserver-xorg-video-via 1:0.2.2-6 X.Org X server -- VIA display driver ii xserver-xorg-video-voodoo 1:1.2.0-1 X.Org X server -- Voodoo display driver I'm using the VIA driver, and it seems I have kbd enabled. From xev, I get the following events when I press and release the § key, then repeat it while also pressing shift. This is with C-t as the escape character (with § as the escape character, I naturally don't see those keypresses with xev). KeyPress event, serial 27, synthetic NO, window 0x161, root 0x49, subw 0x0, time 243070803, (424,896), root:(425,897), state 0x0, keycode 49 (keysym 0xa7, section), same_screen YES, XLookupString gives 1 bytes: (a7) § XmbLookupString gives 1 bytes: (a7) § XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0x161, root 0x49, subw 0x0, time 243070928, (424,896), root:(425,897), state 0x0, keycode 49 (keysym 0xa7, section), same_screen YES, XLookupString gives 1 bytes: (a7) § XFilterEvent returns: False KeyPress event, serial 27, synthetic NO, window 0x161, root 0x49, subw 0x0, time 243072176, (424,896), root:(425,897), state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 27, synthetic NO, window 0x161, root 0x49, subw 0x0, time 243072576, (424,896), root:(425,897), state 0x1, keycode 49 (keysym 0xbd, onehalf), same_screen YES, XLookupString gives 1 bytes: (bd) ½ XmbLookupString gives 1 bytes: (bd) ½ XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0x161, root 0x49, subw 0x0, time 243072663, (424,896), root:(425,897), state 0x1, keycode 49 (keysym 0xbd, onehalf), same_screen YES, XLookupString gives 1 bytes: (bd) ½ XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0x161, root 0x49, subw 0x0, time 243073064, (424,896), root:(425,897), state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False which looks sane, as far as I can tell. Regards, /Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe.
Bug#507568: Documentation for start-stop-daemon says default signal is 15 (TERM) and 9 (KILL). Which should it be?
Package: dpkg Version: 1.13.25 Hi, the manual page for start-stop-daemon says -s|--signal signal With --stop, specifies the signal to send to processes being stopped (default 15). and later on, Note: unless --pidfile is specified, start-stop-daemon behaves similar to killall(1). start-stop-daemon will scan the process table looking for any processes which match the process name, uid, and/or gid (if specified). Any matching process will prevent --start from starting the daemon. All match- ing processes will be sent the KILL signal if --stop is specified. For dae- mons which have long-lived children which need to live through a --stop you must specify a pidfile. which seems to say that the default signal is 9 (KILL) rather than 15 (TERM). This is contradictory and confusing. The manual page should be clear on what's the default signal to send, and it would be nice to use the symbolic namn, not just the numeric value. The paragraph above saying KILL is used seems to have been introduced as a patch for bug #211856, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211856 Regards, /Niels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507597: ratpoison not using ~/.ratpoisonrc
Package: ratpoison
Version: 1.4.3-1
I use the following .ratpoisonrc,
8---
escape section
bind onehalf meta
8
(The key in question is located between ESC and TAB on my Swedish
keyboard).
I start X from the command line using startx, and I start ratpoison
from my .xinitrc file.
After upgrading from Etch to Lenny, this no longer works. When I start
ratpoison, I get the default escape and meta keys, C-t and t, not the
ones I have configured in my startup file.
I have checked, using strace, that ratpoison reads the file,
open(/home/nisse/.ratpoisonrc, O_RDONLY) = 4
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=33, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f46000
read(4, escape section\nbind onehalf meta\n..., 4096) = 33
read(4, ..., 4096)= 0
close(4)= 0
I also think the command parser recognizes the commands, since it
works fine to configure the keys from an xterm command line,
$ ratpoison -c 'escape section'
$ ratpoison -c 'bind onehalf meta'
Or maybe I should say almost works, after the above command, the
§-key acts correctly as the ratpoison escape key. The sequence § ½
works in emacs, in that it inserts a § character. However, the § ½
sequence does not work in xterm, where it seems to have no effect at
all, the behaviour is the same as if I type § C-g.
I'm puzzled.
Regards,
/Niels
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415034: chiark-utils FTBFS -- who is to blame?
Steve Langasek [EMAIL PROTECTED] writes: No it's not right. No software should be required to care about the implementation details of the library it's using, *especially* when dynamic linking on an OS that gets this right (such as GNU/Linux). Just a detail: The dependence on gmp is not merely an implementation detail, it's part of the interface (the public nettle functions use gmp's mpz_t for passing around bignums). The reason I (upstream) recommend that applications using nettle link explicitly with -lnettle -lgmp, is that that seems to be the easiest portable way to get correct linking, across various systems, and with both dynamic and static linking. Debian priorities may well be different, since you always use dynamic linking and ELF. Do the chiark programs use the public-key parts of nettle? I consider it a bug that programs that aren't using gmp-dependent functions of nettle still must to link with gmp at runtime (assuming that nettle was configured with public key support, and dynamic linking is used; this worked better with static linking). A future version of nettle will split the library into two files, one that depends on gmp, and one that does not. Regards, /Niels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406499: Problem with xorg configuration
Frans Pop [EMAIL PROTECTED] writes: Do you have an original Synaptics touchpad, or rather an Alps one (see /proc/bus/input/devices)? If you have an Alps, it is normal that you need to tune the configuration somewhat; see docs in: /usr/share/doc/xserver-xorg-input-synaptics/ It turns out it's an alps (I don't really know much about PC hardware). I: Bus=0011 Vendor=0002 Product=0008 Version= N: Name=AlpsPS/2 ALPS DualPoint TouchPad P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input3 H: Handlers=mouse1 event3 ts1 B: EV=f B: KEY=420 0 7 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=103 If you want to follow up please file a bug report against the package xserver-xorg-input-synaptics. I don't know if that's the installer's responsibility, or the xorg package (but I suspect it's at least partly the installer's since the isntaller did the hardware detection underlying the decision to install the xorg synaptics module (and the ivtvdev driver)). The important thing is that xserver should work *out of the box* when installing debian, with no configuration on the user's part (including reasonable pointer acceleration) . As your installation was basically successful, I'm closing your report. Thank you for filing it and good luck with the new system. X was broken in the default desktop install (with known problems). Except that, the install was successful. I have *always* had some trouble or the other to get X to work when installing debian. But at least it's improving, with the xorg stuff. Thanks, /Niels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406499: Problem with xorg configuration
Package: installation-reports Boot method: CD Image version: http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-CD-1.iso Date: 2007-01-09, snapshot downloaded the same day. Machine: Laptop, Dell Latitude D600 Processor: Intel(R) Pentium(R) M processor 1.80GHz Memory: 512 MB Partitions: FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hda1 ext3 264445154829 95963 62% / tmpfstmpfs 258212 0258212 0% /lib/init/rw udev tmpfs 1024096 10144 1% /dev tmpfstmpfs 258212 0258212 0% /dev/shm /dev/hda9 ext328621052578596 26588576 3% /home /dev/hda8 ext3 381138 10328351132 3% /tmp /dev/hda5 ext3 4806904 3082808 1479912 68% /usr /dev/hda6 ext3 2885780624596 2114596 23% /var /dev/nnpfs0 nnpfs 2097152 100 2097102 1% /afs Output of lspci -nn and lspci -vnn: lspci -nn (for lspci -vnn output is appended at the end of this message): 00:00.0 Host bridge [0600]: Intel Corporation 82855PM Processor to I/O Controller [8086:3340] (rev 03) 00:01.0 PCI bridge [0604]: Intel Corporation 82855PM Processor to AGP Controller [8086:3341] (rev 03) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 81) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 01) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01) 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 01) 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon R250 [Mobility FireGL 9000] [1002:4c66] (rev 02) 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5705M Gigabit Ethernet [14e4:165d] (rev 01) 02:01.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller [1217:7113] (rev 20) 02:01.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller [1217:7113] (rev 20) 02:03.0 Network controller [0280]: Broadcom Corporation BCM4309 802.11a/b/g [14e4:4324] (rev 03) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: I selected the desktop task during the installation process. This generated an xorg configuration file specifying the display driver ivtvdev, and this was also the only driver that was installed on the system. Then X failed to start, with an error message like No device found (sorry, I didn't keep the log). After intalling the vesa driver (xserver-xorg-video-vesa), X works fine, but without any fancy hardware acceleration. Maybe the radeon driver from the radeon driver from the xserver-xorg-video-ati packege should work better (I haven't tried yet). Anyway, I think the installation program should be able to figure out that the machine has a radeon graphics card and either install a specialized driver for it (if one exists), or fall back to the general vesa driver. I have no idea which hardware the ivtvdev is intended for, but it didn't work with mine. So X doesn't work out of the box. THat was the only major problem during the install, everything else wore nice and smooth. But I also have some minor problems and complaints: * The automatic X configuration also used the synaptics touchpad driver. That's nice, but the defaults for this driver makes moving the X pointer very very very slow. I added Option MaxSpeed 5.0 Option MinSpeed 2.0 to the configuration. I don't know exactly what this means, but the results are more workable. The defaults needs some tweaking here. * Every five minutes, I get the following mesages written to syslog Jan 11 14:04:01 maskros kernel: bcm43xx: PHY connected Jan 11 14:04:01 maskros kernel:
Bug#393400: Source package contains non-free IETF RFC/I-D's
About selecting a free input file for the nettle testsuite, I wrote: It would be better to shop around at project gutenberg. I think I've found a worthy candidate text: The short story The Gold-Bug written by Edgar Allan Poe. The author died in 1849, so until the US decides to extend copyright even further, the text is in the public domain. See http://www.gutenberg.org/etext/2043. Regards, /Niels
Bug#393400: Source package contains non-free IETF RFC/I-D's
Simon Josefsson [EMAIL PROTECTED] writes: How about the Nettle manual? That seems to be appropriate, too. No, it's inconvenient to use a file that is subject to updates (for every update to the file, the testcase would have to be updated as well, which kind-of defeats the idea of automatic regression testing). That's why I liked using an RFC; they are never updated after publication. And using a fixed outdated version of the nettle manual seems silly. It would be better to shop around at project gutenberg. /Niels
Bug#360933: libc6: calling chroot breaks pthread_exit/pthread_cancel
Package: libc6 Version: 2.3.2.ds1-22 Severity: normal When calling pthread_exit in a program which has called chroot, the program exits with the error message libgcc_s.so.1 must be installed for pthread_cancel to work The problem is that the nptl library needs the stack unwind code from libgcc_s.so.1, and it uses dlopen to load this library. I tried to install arlad, configured to use posix threads. This program chroots to /usr/arla/cache at startup, before doing any interesting thread operations. Then the later dlopen by the nptl code naturally fails, and it displays the above error message and calls _exit. I'm not terribly familiar with the POSIX standard or with POSIX threads, but it seems unintuitive and probably not standards compliant that a threaded server program can't use chroot at startup. A workaround seems to be to link the program with an explicit -lgcc_s on the command line, in addition to -lpthread, but as far as I understand, one should never need to link explicitly with libgcc_s. Regards, /Niels -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16.1-nisse Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information
