Bug#544876: perdition: Perdition needs vanessa_socket 0.0.8
Package: perdition Version: 1.18~rc1-1 Severity: grave Justification: renders package unusable Perdition 1.18~rc1 needs symbols provided by vanessa_socket 0.0.8. I will upload 1.18~rc1-2 with the relevant build dependency fixed. Noting that currently vanessa_socket 0.0.8 is in NEW. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_AU.utf8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#434829: heartbeat: Incorect path for crm.dtd and other scripts
Package: heartbeat Version: 2.1.1-1 Severity: grave Justification: renders package unusable Just prior to the release of 2.1.1 a number of files, including crm.dtd were relocated from /usr/lib/heartbeat and /usr/share/heartbeat. In order to ease the pain of this relocation compatibility symlinks were put in place and, accordingly, many references to these files were not updated to use the new path. Unfortunately the compatibility symlink creation was added to the RPM .spec file and nowhere else, and for this reason they were not included in the Debian package - it turns out the addition to the .spec file also didn't work, but that is a different story. This has been loged as Heartbeat bugzilla bug 1661, and there is a related bug 1665. http://old.linux-foundation.org/developer_bugzilla/show_bug.cgi?id=1661 http://old.linux-foundation.org/developer_bugzilla/show_bug.cgi?id=1665 This has been fixed in upstream mecurual as changesets 13dc55dece11, 0c8dc61feeb2 and 635bd958ed2b. http://hg.linux-ha.org/dev/rev/13dc55dece11 http://hg.linux-ha.org/dev/rev/0c8dc61feeb2 http://hg.linux-ha.org/dev/rev/635bd958ed2b I will relase 2.1.1-2 ASAP with these patches applied. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (190, 'unstable'), (180, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) (ignored: LC_ALL set to ja_JP.utf8) Shell: /bin/sh linked to /bin/bash Versions of packages heartbeat depends on: ii adduser 3.103Add and remove users and groups ii iproute 20070313-1 Professional tools to control the ii iputils-ping3:20070202-1 Tools to test the reachability of ii libc6 2.5-11 GNU C Library: Shared libraries ii libglib1.2 1.2.10-17The GLib library of C routines ii libnet1 1.1.2.1-2library for the construction and h pn libpils0none (no description available) ii libsensors3 1:2.10.3-1 library to read temperature/voltag pn libsnmp9none (no description available) ii libssl0.9.8 0.9.8e-5 SSL shared libraries pn libstonith0 none (no description available) ii libuuid11.40.1-1 universally unique id library ii libwrap07.6.dbs-13 Wietse Venema's TCP wrappers libra ii python 2.4.4-6 An interactive high-level object-o ii python-central 0.5.14 register and build utility for Pyt Versions of packages heartbeat recommends: ii iptables1.3.6.0debian1-5 administration tools for packet fi ii logrotate 3.7.1-3 Log rotation utility ii sysklogd [system-log-da 1.4.1-21 System Logging Daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432441: heartbeat: FTBFS: unmet build dep modutils
On Wed, Jul 18, 2007 at 08:22:00PM -0700, Steve Langasek wrote: Hi Horms, This has been fixed upstream, I am expecting them to release shortly and this bug should be closed in the subsequent upload. Is there any more definite ETA? This is currently the major issue holding the net-snmp soname transition out of testing. I've been told this month. I can make an interim upload of 2.0.8 + this fix if you like. I could make such an upload today unless the sky falls in. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432441: FTBFS: Unmet build dep modutils
tag 432441 +pending thanks This has been fixed upstream, I am expecting them to release shortly and this bug should be closed in the subsequent upload. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419617: uim: is not upgradable from uim 1.2
tag 419617 -unreproducible thanks I am removing the unreproducable tag from this bug as it is trivially reproducable. 1) have an uim-common 1:1.4.1-1 installed 2) aptitude update 3) aptitude upgrade -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415393: uim: is not upgradable from uim 1.2
severity 419617 grave
thanks
I think that both #419617 and #415393 are caused by
uim-common missing a dependancy on libuim5 (= ${binary:Version})
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419617;msg=32
Is it possible to get this fixed, its really quite broken.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393574: heartbeat-2: mknod in maintainer script
On Mon, Oct 16, 2006 at 11:18:06PM +0200, Aurelien Jarno wrote: Package: heartbeat-2 Version: 2.0.7-1 Severity: serious Justification: Policy 10.6 Maintainer scripts should not create device files directly. They should call makedev instead. Refer to Policy Manual, section 10.6 for details. The problem is that the call to mknod is not creating a device, it is creating a fifo, which is not an operation created by makedev. I'm not sure what the best fix, if any, is for this. When I asked around a very long time ago, I was advised to just leave the call to mknod inside the maintainer script. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393572: heartbeat: mknod in maintainer script
On Mon, Oct 16, 2006 at 11:14:56PM +0200, Aurelien Jarno wrote: Package: heartbeat Version: heartbeat Severity: serious Justification: Policy 10.6 Maintainer scripts should not create device files directly. They should call makedev instead. Refer to Policy Manual, section 10.6 for details. The problem is that the call to mknod is not creating a device, it is creating a fifo, which is not an operation created by makedev. I'm not sure what the best fix, if any, is for this. When I asked around a very long time ago, I was advised to just leave the call to mknod inside the maintainer script. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380289: Processed: reopening 380289, found 380289 in 2.0.5-8, closing 380289
Thanks for cleaning that up -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380180: heartbeat: portblock syntax errors in 1.2.3-9sarge5
On Fri, Jul 28, 2006 at 09:57:24AM +0200, Kostja Siefen wrote: Package: heartbeat Version: 1.2.3-9sarge5 Severity: grave Tags: patch Justification: renders package unusable After upgrading to 1.2.3-9sarge5, heartbeat kept rebooting the system as there were errors running the portblock resource script. This bug applies to people which use portblock as heartbeat service to drop incoming network packets when service takeover. The syntax error is due to a missing iptables path which results in command not found errors in /etc/ha.d/resource.d/portblock. Fixing is simple, patch is attached (putting iptables back into place). Thanks. I suspect that the problem is that ther eis a missing build depenancy on iptables, and thus its path is not being auto-detected and filled in at build-time. I'll get this fixed for the next release. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379904: heartbeat: Local DoS due to world-writable shared memory [CVE-2006-3815]
On Wed, Jul 26, 2006 at 11:18:57AM +0200, Martin Pitt wrote: Package: heartbeat Version: 1.2.4-12 Severity: grave Tags: security patch Hi! Recently, a local DoS due to world-writable/readable shared memory permissions was found and fixed in heartbeat: Upstream fix: http://cvs.linux-ha.org/viewcvs/viewcvs.cgi/linux-ha/heartbeat/heartbeat.c?r1=1.513r2=1.514 This has been assigned CVE-2006-3815. Please mention this number in the changelog when you fix this to ease tracking. Thanks, I will get a new relase out for this. Though it probably will not be until next week. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379071: heartbeat-2: /var/lib/heartbeat/pengine is missing
Package: heartbeat-2 Version: 2.0.6-1 Severity: serious The following required directory is missing /var/lib/heartbeat/pengine (ownership hacluster:haclient) I will fix this in the next upload. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378450: ldirectord-2 mail spamming and autostart
Hi,
here are patches for two emailalert problems.
The first patch fixes things so that email will no longer be
sent if no address is specified. It also cleans up the logic a bit.
The second patch adds global emailalert and emailalertfreq parameters,
that can be overriden by the existing per-virtual settings.
While investigating this I made a short list of other emailalert related
things that I would like to fix. So this means that the patches are
still evolving. I'll try and get a complete set together in the
not to distant future.
* Use hash instead of array for managing freq, and only add
entries that need to resend alerts at any given point of time.
* Add a body to the message - repeating the subject should be fine for
now
* Add emailalert and emailalertfreq to sample ldirectord.cf
* Log when alerts are sent
バイナリー・ファイル/dev/nullとto-work/.ldirectord.swpは違います
--- from-0002/ldirectord
+++ to-work/ldirectord 2006-07-17 22:25:11.0 -0400
@@ -1834,13 +1834,7 @@ sub ld_main
sleep $CHECKINTERVAL;
}
- my $currenttime=time();
- foreach my $es (@EMAILSTATUS){
- if (($es-{alerttime} 0 ) ($currenttime -
$es-{alerttime} = $es-{emailalertfreq})){
- ld_emailalert(Inaccessible real server:
$es-{server}, $es-{emailalert});
- ld_set_email_status($es-{server},
$currenttime);
- }
- }
+ ld_emailalert_resend();
}
}
@@ -2639,18 +2633,14 @@ sub _remove_service {
. $ipvsadm_args $rforw -w 0);
ld_log(Quiescent $log_args (Weight set to 0));
}
- if(defined($$v{emailalert})) {
- ld_emailalert(Quiescent $log_args (Weight set to
0),$$v{emailalert});
- ld_set_email_status($currentserver, $currenttime);
- }
+ ld_emailalert(Quiescent $log_args (Weight set to 0),
+ $$v{emailalert}, $currentserver, $currenttime);
}
else {
system_wrapper($IPVSADM -d $ipvsadm_args);
ld_log(Deleted $log_args);
- if(defined($$v{emailalert})) {
- ld_emailalert(Deleted $log_args,$$v{emailalert});
- ld_set_email_status($currentserver, $currenttime);
- }
+ ld_emailalert(Deleted $log_args,$$v{emailalert},
+ $currentserver, $currenttime);
}
}
@@ -2704,19 +2694,16 @@ sub _restore_service {
get_forward_flag($or-{forward}) eq $rforw){
system_wrapper($IPVSADM -e $ipvsadm_args);
ld_log(Restored $log_args (Weight set to $rwght));
- if(defined($$v{emailalert})) {
- ld_emailalert(Restored $log_args (Weight set
to $rwght),$$v{emailalert});
- ld_set_email_status($currentserver, 0);
- }
+ ld_emailalert(Restored $log_args .
+ (Weight set to $rwght),
+ $$v{emailalert}, $currentserver, 0);
}
}
else {
system_wrapper($IPVSADM -a $ipvsadm_args);
ld_log(Added $log_args (Weight set to $rwght));
- if(defined($$v{emailalert})) {
- ld_emailalert(Added $log_args (Weight set to
$rwght),$$v{emailalert});
- ld_set_email_status($currentserver, 0);
- }
+ ld_emailalert(Added $log_args (Weight set to $rwght),
+ $$v{emailalert}, $currentserver, 0);
}
}
@@ -3043,19 +3030,46 @@ sub ld_log
# 1 on error
sub ld_emailalert
{
- my ($emailsubject,$emailto) = (@_);
- require Mail::Send;
+ my ($emailsubject, $emailto, $currentserver, $currenttime) = (@_);
my $emailmsg;
my $emailfh;
-
+ my $status = 0;
+
+ if ($emailto eq ) {
+ return 0;
+ }
+
+ use Mail::Send;
+
unless ($emailmsg = new Mail::Send Subject=$emailsubject, To=$emailto
and $emailfh = $emailmsg-open
and print $emailfh
and $emailfh-close) {
ld_log(failed to send email message\n);
- return 1;
+ $status = 1;
+ }
+
+ ld_set_email_status($currentserver, $currenttime);
+
+ return($status);
+}
+
+# ld_emailalert_resend
+# Resend email alerts as neccessary
+# pre: none
+# post: EMAILSTATUS array is updated and alears are sent as neccessary
+# return: none
+sub ld_emailalert_resend
+{
+ my $currenttime=time();
+
Bug#378450: ldirectord-2: unwanted emailalerts
Package: ldirectord-2 Version: 2.0.6-1 Severity: serious ldirectord-2 has been reported to be trying to send emailalerts even if not configured to do so. I haven't verified this behaviour myself, and I don't have time to right now. This bug should hold ldirectord-2 out of etch, until I (or someone else) gets a chance to investigate further. If worst comes to worse, email alearts can just be stripped out of the ldirectord source code. But I doubt anything that drastic is required. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375941: heartbeat-2: uses adduser when it may not be available
On Mon, Jul 03, 2006 at 05:50:43PM -0400, Justin Pryzby wrote: I think the recommendation is to never remove a dynamically created user, precisely to avoid another user with the same ID owning those files. Excellent, thanks for the info. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375507: heartbeat: uses adduser when it may not be available
On Mon, Jun 26, 2006 at 02:53:55PM +0100, James Troup wrote: Package: heartbeat Version: 1.2.4-9 Severity: serious Justification: breaks buildds | Purging configuration files for heartbeat ... | /var/lib/dpkg/info/heartbeat.postrm: line 25: deluser: command not found Is it sufficient just to make the call do deluser conditional on it existing (or let it ignore the error) ? Or do I need to move deluser into prerm somehow? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369815: [Linux-ha-dev] Re: Bug#369815: ships binary in /etc
On Tue, Jun 06, 2006 at 11:01:25PM -0600, Alan Robertson wrote: Horms wrote: On Thu, Jun 01, 2006 at 03:24:48PM +0200, Marc 'HE' Brockschmidt wrote: Package: heartbeat Severity: serious Heya, Let's see what the FHS says: No binaries should be located under /etc. [3.4] Now, what does heartbeat do? [EMAIL PROTECTED]:/tmp/he$ dpkg-deb -x heartbeat_1.2.4-8_i386.deb bar [EMAIL PROTECTED]:/tmp/he$ file bar/etc/ha.d/resource.d/IPv6addr bar/etc/ha.d/resource.d/IPv6addr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped Unfortunately heartbeat (for fairly broken reasons IMHO) really needs those files there. Could we symlink 'em somewhere? Yes, I think that is a good solution (short of rearanging the resource paths completely). I can do this fairly easily in the Debian packaging and intend to do so shortly. Do you want me to shoe-horn this into the relevant Makefile.am, or just leave it as a Debian thing? -- Horms http://www.vergenet.net/~horms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369815: ships binary in /etc
On Thu, Jun 01, 2006 at 03:24:48PM +0200, Marc 'HE' Brockschmidt wrote: Package: heartbeat Severity: serious Heya, Let's see what the FHS says: No binaries should be located under /etc. [3.4] Now, what does heartbeat do? [EMAIL PROTECTED]:/tmp/he$ dpkg-deb -x heartbeat_1.2.4-8_i386.deb bar [EMAIL PROTECTED]:/tmp/he$ file bar/etc/ha.d/resource.d/IPv6addr bar/etc/ha.d/resource.d/IPv6addr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped Unfortunately heartbeat (for fairly broken reasons IMHO) really needs those files there. -- Horms http://www.vergenet.net/~horms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369815: ships binary in /etc
On Mon, Jun 05, 2006 at 10:46:02AM +0100, Stephen Gran wrote: This one time, at band camp, Horms said: On Thu, Jun 01, 2006 at 03:24:48PM +0200, Marc 'HE' Brockschmidt wrote: Let's see what the FHS says: No binaries should be located under /etc. [3.4] Now, what does heartbeat do? [EMAIL PROTECTED]:/tmp/he$ dpkg-deb -x heartbeat_1.2.4-8_i386.deb bar [EMAIL PROTECTED]:/tmp/he$ file bar/etc/ha.d/resource.d/IPv6addr bar/etc/ha.d/resource.d/IPv6addr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped Unfortunately heartbeat (for fairly broken reasons IMHO) really needs those files there. Can't it be a symlink? I didn't realise that would resolve the problem. Yes, I believe it can be. I will see about making it so. -- Horms http://www.vergenet.net/~horms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352027: acknowledged by developer (Bug#352027: fixed in heartbeat 1.2.4-3)
On Sat, Feb 11, 2006 at 09:43:09PM -0800, Steve Langasek wrote: On Sun, Feb 12, 2006 at 01:17:03PM +0900, Horms wrote: On Sat, Feb 11, 2006 at 03:06:36PM -0800, Steve Langasek wrote: On Sat, Feb 11, 2006 at 09:50:20PM +0900, Horms wrote: On Sat, Feb 11, 2006 at 12:51:00PM +0100, Bastian Blank wrote: reopen 352027 severity 352027 serious retitle 352027 heartbeat - pre-depends on adduser without consensus What exactly is that supposed to mean? That we all need to agree before adding the pre-depends? That we aren't sure if it solves the problem? That pre-depends should be added with extreeme caution? Are there other options available? I'm pretty ambivilent about how this problem gets fixed. Just let me know what you decide. Policy says that pre-depends must be discussed on debian-devel. So post to debian-devel, wait a few days, then close this bug again. :) I don't anticipate any objections, adduser is commonly found in pre-depends and heartbeat is not a high-priority package (in the Priority: sense). Ok, understood. Adduser is only used to create a system group and user on install if it doesn't exist. Is there an alternate way to do this that wouldn't require a pre-depends? Don't ship files in your package that are owned by the user/group, just call adduser and create any files/directories you need to in the postinst? Thats exactly what is happening :-) Anyway, ought to be discussed on -devel :) Fine, though I would have thought that this is a fairly common scenario with a canned solution. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352027: acknowledged by developer (Bug#352027: fixed in heartbeat 1.2.4-3)
On Sun, Feb 12, 2006 at 12:16:31AM -0800, Steve Langasek wrote: On Sun, Feb 12, 2006 at 05:07:57PM +0900, Horms wrote: On Sat, Feb 11, 2006 at 09:43:09PM -0800, Steve Langasek wrote: On Sun, Feb 12, 2006 at 01:17:03PM +0900, Horms wrote: On Sat, Feb 11, 2006 at 03:06:36PM -0800, Steve Langasek wrote: On Sat, Feb 11, 2006 at 09:50:20PM +0900, Horms wrote: On Sat, Feb 11, 2006 at 12:51:00PM +0100, Bastian Blank wrote: reopen 352027 severity 352027 serious retitle 352027 heartbeat - pre-depends on adduser without consensus What exactly is that supposed to mean? That we all need to agree before adding the pre-depends? That we aren't sure if it solves the problem? That pre-depends should be added with extreeme caution? Are there other options available? I'm pretty ambivilent about how this problem gets fixed. Just let me know what you decide. Policy says that pre-depends must be discussed on debian-devel. So post to debian-devel, wait a few days, then close this bug again. :) I don't anticipate any objections, adduser is commonly found in pre-depends and heartbeat is not a high-priority package (in the Priority: sense). Ok, understood. Adduser is only used to create a system group and user on install if it doesn't exist. Is there an alternate way to do this that wouldn't require a pre-depends? Don't ship files in your package that are owned by the user/group, just call adduser and create any files/directories you need to in the postinst? Thats exactly what is happening :-) Uh, in that case there shouldn't be any reason to create the user in the *pre*inst, right? Ok, I was confused. Its exactly what should be happening. I'll rearange things so that it is. And re-upload. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352027: acknowledged by developer (Bug#352027: fixed in heartbeat 1.2.4-3)
On Sat, Feb 11, 2006 at 12:51:00PM +0100, Bastian Blank wrote: reopen 352027 severity 352027 serious retitle 352027 heartbeat - pre-depends on adduser without consensus What exactly is that supposed to mean? That we all need to agree before adding the pre-depends? That we aren't sure if it solves the problem? That pre-depends should be added with extreeme caution? Are there other options available? I'm pretty ambivilent about how this problem gets fixed. Just let me know what you decide. Presumably these alterations to 352027 also apply to 352158. Could you please update that bug too? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352027: acknowledged by developer (Bug#352027: fixed in heartbeat 1.2.4-3)
On Sat, Feb 11, 2006 at 03:06:36PM -0800, Steve Langasek wrote: On Sat, Feb 11, 2006 at 09:50:20PM +0900, Horms wrote: On Sat, Feb 11, 2006 at 12:51:00PM +0100, Bastian Blank wrote: reopen 352027 severity 352027 serious retitle 352027 heartbeat - pre-depends on adduser without consensus What exactly is that supposed to mean? That we all need to agree before adding the pre-depends? That we aren't sure if it solves the problem? That pre-depends should be added with extreeme caution? Are there other options available? I'm pretty ambivilent about how this problem gets fixed. Just let me know what you decide. Policy says that pre-depends must be discussed on debian-devel. So post to debian-devel, wait a few days, then close this bug again. :) I don't anticipate any objections, adduser is commonly found in pre-depends and heartbeat is not a high-priority package (in the Priority: sense). Ok, understood. Adduser is only used to create a system group and user on install if it doesn't exist. Is there an alternate way to do this that wouldn't require a pre-depends? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339485:
merge 339487 339485 thanks In article [EMAIL PROTECTED] you wrote: This should be merged with 339487 (typed --body option rather than --body-file) Merging as requested. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Tue, Nov 01, 2005 at 09:35:35AM +0100, Marco d'Itri wrote: On Nov 01, Rusty Russell [EMAIL PROTECTED] wrote: Hmm, if the root filesystem is read-only, then the locking will fail (you need to open a file read/write to get an exclusive fcntl lock). Perhaps this is happening to you? If not, please check again that you Sure, all of this happens when / is read only. Perhaps a rw tmpfs could save the day. Just an idea. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333522: linux-image-2.6.14-1-686-smp: occurs in stock linux-image as well
On Mon, Oct 31, 2005 at 03:10:29PM -0800, Paul Traina wrote: Package: linux-image-2.6.14-1-686-smp Version: 2.6.14-1 Followup-For: Bug #333522 udev/unstable uptodate 0.071-1 Just to cover the blanks, it is occuring as well with stock 2.6.14 debian kernels. This is a straight kernel built with an up to date initramfs tools. initramfs-tools rebuilt the initramfs several times (I've beend debugging evms) while running 2.6.14 and depmod -a's have occured. Let me know if I can test/help/hack. I'm 99.9% certain its due to modprobe being called in parallel by the new udev code. Don't understand why m-i-t isn't serializing the right bits. Yes, that seems to be the current school of thought. Rusty has been thinking it over with Marco, but we are yet to find the solution. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: udev issue
On Sun, Oct 30, 2005 at 09:32:42PM +0100, Sven Luther wrote: On Sun, Oct 30, 2005 at 05:23:42PM +0100, Elimar Riesebieter wrote: Hi all, I am running 2.6.14 from Debian sources on my PB5,6. Booting gives some Unknown issuses: $ dmesg | grep Unk ohci_hcd: Unknown symbol usb_hcd_pci_suspend ohci_hcd: Unknown symbol usb_hcd_pci_probe ohci_hcd: Unknown symbol usb_trylock_device ohci_hcd: Unknown symbol usb_disabled ohci_hcd: Unknown symbol usb_unlock_device ohci_hcd: Unknown symbol usb_lock_device ohci_hcd: Unknown symbol usb_calc_bus_time ohci_hcd: Unknown symbol usb_hcd_pci_resume ohci_hcd: Unknown symbol usb_hcd_giveback_urb ohci_hcd: Unknown symbol usb_set_device_state ohci_hcd: Unknown symbol usb_hcd_pci_remove ohci_hcd: Unknown symbol usb_hcd_pci_suspend ohci_hcd: Unknown symbol usb_hcd_pci_probe ohci_hcd: Unknown symbol usb_trylock_device ohci_hcd: Unknown symbol usb_disabled ohci_hcd: Unknown symbol usb_unlock_device ohci_hcd: Unknown symbol usb_lock_device ohci_hcd: Unknown symbol usb_calc_bus_time ohci_hcd: Unknown symbol usb_hcd_pci_resume ohci_hcd: Unknown symbol usb_hcd_giveback_urb ohci_hcd: Unknown symbol usb_set_device_state ohci_hcd: Unknown symbol usb_hcd_pci_remove The usb2 iface seems to work properly. Suggestions? This is a strange bug in the 2.6.12+ kernel packages. For some obscure reason, neither at postinst time nor at boot time the depmod get's regenerated properly, so simply run depmod yourself and it goes away. If you have time to investigate this, it would be really appreciated. Actually, I believe it is #333052 for which a solution still alludes us. Although it does seem to be a modprobe problem tickled by recent changes to udev. http://bugs.debian.org/cgi-bin/333052 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: does this affect etch/sid?
On Sun, Oct 30, 2005 at 03:42:24PM -0500, Joey Hess wrote: This bug seems to be full of discussion of sarge, and was closed until 3.0.14a-4 didn't make the cut for sarge. Does it also affect etch and sid? If not, could you close it for those, so we can stop tracking it as a security issue for them? I believe that this is a 2.4.27 bug. 2.4.27-11, the sid version, still has this bug. I am still looking for someone to test or comment on the patch I posted. Though I am tempted to put it into 2.4.27-12 untested. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335993: acknowledged by developer (Well, this bug presented itself in experimental, and now is fixed there)
On Sat, Oct 29, 2005 at 12:48:15AM -0700, Debian Bug Tracking System wrote: Version: 10.002 Hi, Since the bug is fixed in an upload to experimental, and the bug itself was never in Sid, ... Thats fine by me. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336295: linux-2.6 arch specific include/asm-$(ARCH)/ headers are not included in linux-headers-2.6.14-1 packages
On Sat, Oct 29, 2005 at 12:41:55PM +0300, Modestas Vainius wrote:
Hi,
the bug title says almost everything. include/asm-${ARCH} headers
are missing from linux-headers-2.6.14-1 as of revision -1 (tested
on i836 and amd64). This makes linux-headers almost unusable for
building external modules.
This is likely the bug in the current kernel-package in unstable.
Please reassign if so.
Thanks for pointing this out, I'm guessing its actually a problem
in linux-2.6's packaging (the stuff in debian/) rather than
kernel-packaging. In any case it shouldn't be too hard to resolve
and it should go into -2, soon.
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336295: Bug#336412: linux-headers-2.6.14-1-686: missing links on headers' tree render package unusable
On Sun, Oct 30, 2005 at 05:36:23AM +0100, Mau wrote: Package: linux-headers-2.6.14-1-686 Version: 2.6.14-1 Severity: grave Justification: renders package unusable many links in the headers' tree are not created by the package; every package installation gives unpredictable results, sometimes a link was made, sometimes not. Furthermore an include/asm link to not existing asm-i386 dir is present (the package only supplies asm-generic?). These problems make compilation against these headers impossible, so this package is now in an unusable state. Thanks, this is actually a duplicate of 336295, lets track it there. http://bugs.debian.org/336295 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Fri, Oct 28, 2005 at 05:24:44PM +1000, Rusty Russell wrote: On Thu, 2005-10-27 at 10:10 +0200, Marco d'Itri wrote: And then it fails for ehci-hcd too (which is not loaded at all). Rusty, do you have other ideas for debugging? I have reread the bug reports, and meditated on this issue some more. This is a possibility I was aware of when I changed to code to drop the module_mutex before calling mod-init(), years ago. Sorry it took so long. Thanks, very much appreciated. Hopefully this solves our woes. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336153: kernel-image-2.6.8-2-386: Filesystem errors while writing to DM disk
Is it possible for you to see if this problem also exists in 2.6.12? There is a 2.6.12-5.99.sarge1 backport at http://packages.vergenet.net/testing/linux-2.6/ -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328707: kernel-source-2.4.27: Compile fails
On Fri, Oct 28, 2005 at 08:26:45PM -0400, micah wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Björn Andersson wrote:
{standard input}: Assembler messages:
{standard input}:737: Error: suffix or operands invalid for `mov'
{standard input}:738: Error: suffix or operands invalid for `mov'
{standard input}:832: Error: suffix or operands invalid for `mov'
{standard input}:833: Error: suffix or operands invalid for `mov'
{standard input}:874: Error: suffix or operands invalid for `mov'
{standard input}:875: Error: suffix or operands invalid for `mov'
{standard input}:877: Error: suffix or operands invalid for `mov'
{standard input}:889: Error: suffix or operands invalid for `mov'
distcc[25163] ERROR: compile process.c on localhost failed
make[2]: *** [process.o] Error 1
I believe this has to do with the new binutils in unstable.
I had this same problem and solved it by changing my symlink for
/usr/bin/gcc to point to gcc-3.3 instead of 4.0 for the duration of the
2.4 compile. Clearly this isn't the best solution, but its a work-around.
Strange, kernel-source-2.4.27-11 should be using gcc-3.3, as I
patched the top-level Makefile to do so. But I think I am seeing
this problem too, so I guess there is a hole in there somewhere.
--
Horms
Bug#335993: kernel-package: Problem with kernel_version.mk causes build fauilure
Package: kernel-package Version: 10.001 Severity: grave Tags: experimental Justification: renders package unusable Hi, first up sorry if this is known, it only manifests in 10.001, I built (and uploaded) linux-2.6-2.6.13+2.6.14-rc4 for i386, using 9.008.4, the version in sid. I've appended a build log below, but basically it seems to fail when trying to build linux-2.6-2.6.13+2.6.14-rc4 because of some issue in kernel_version.mk Let me know if you want me to investigate further, it seems to be trivial to reproduce over here. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-rc4-1-686-smp Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) (ignored: LC_ALL set to ja_JP.eucJP) Versions of packages kernel-package depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii dpkg-dev 1.13.11 package building tools for Debian ii gcc [c-compiler] 4:4.0.2-1 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-10 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.4-9 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.2-3 The GNU C compiler ii make 3.80-11 The GNU version of the make util ii perl 5.8.7-7 Larry Wall's Practical Extraction Versions of packages kernel-package recommends: ii bzip2 1.0.2-10 high-quality block-sorting file co ii libc6-dev [libc-dev] 2.3.5-7GNU C Library: Development Librari -- no debconf information dpkg-buildpackage: source package is linux-2.6 dpkg-buildpackage: source version is 2.6.13+2.6.14-rc4-0experimental.1 dpkg-buildpackage: source changed by Simon Horman [EMAIL PROTECTED] dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean dh_testdir rm -f version.Debian cd debian; rm -f *.kpatches.arch rm -rf debian/build debian/stamps debian/lib/python/*.pyc dh_clean debian/rules build dh_testdir /usr/bin/make -f debian/rules.gen setup-i386 make[1]: Entering directory `/home/horms/tmp/debian-kernel-test/linux-2.6.13+2.6.14-rc4/linux-2.6-2.6.13+2.6.14-rc4' /usr/bin/make -f debian/rules.real setup-arch SOURCE_VERSION='2.6.13+2.6.14-rc4-0experimental.1' VERSION='2.6.14' SOURCE_UPSTREAM='2.6.13+2.6.14-rc4' ABINAME='rc4' KPKG_ABINAME='' ARCH='i386' UPSTREAM_VERSION='2.6.14-rc4' REVISIONS='0experimental.1' make[2]: Entering directory `/home/horms/tmp/debian-kernel-test/linux-2.6.13+2.6.14-rc4/linux-2.6-2.6.13+2.6.14-rc4' rm -rf debian/build/source mkdir -p debian/build/source cp -al COPYING CREDITS Documentation Kbuild MAINTAINERS Makefile README REPORTING-BUGS arch crypto drivers fs include init ipc kernel lib mm net scripts security sound usr debian/build/source cd debian/build/source; override_version=2.6.13+2.6.14-rc4-0experimental.1 override_revisions=0experimental.1 home=/home/horms/tmp/debian-kernel-test/linux-2.6.13+2.6.14-rc4/linux-2.6-2.6.13+2.6.14-rc4/debian/patches-debian sh /home/horms/tmp/debian-kernel-test/linux-2.6.13+2.6.14-rc4/linux-2.6-2.6.13+2.6.14-rc4/debian/bin/apply W: No version.Debian file, assuming pristine Linux 2.6.13+2.6.14-rc4 amd64-int3-fix.patchOK (+) fbdev-radeon-noaccel.patch OK (+) fs-asfs-2.patch OK (+) ia64-irq-affinity-upfix.patch OK (+) modular-ide.patch OK (+) modular-ide-pnp.patch OK (+) powerpc-calibrate-tau.patch OK (+) powerpc-g3-750cxe.patch OK (+) powerpc-mkvmlinuz-support.patch OK (+) powerpc-serial.patchOK (+) qla2xxx-removed.patch OK (+) sparc64-hme-lockup.patchOK (+) tty-locking-fixes9.patchOK (+) version.patch OK (+) powerpc-mv643xx-hotplug-support.patch OK (+) powerpc-apus.patch OK (+) s390-uaccess-const.patchOK (+) -- 2.6.13+2.6.14-rc4-0experimental.1 fully applied. #make-kpkg does this when building kernel-source. mv debian/build/source/scripts/package/Makefile debian/build/source/scripts/package/Makefile.dist mv debian/build/source/scripts/package/builddeb debian/build/source/scripts/package/builddeb.dist echo # Dummy Makefile debian/build/source/scripts/package/Makefile echo all: debian/build/source/scripts/package/Makefile touch debian/stamps/source make[2]: Leaving directory `/home/horms/tmp/debian-kernel-test/linux-2.6.13+2.6.14-rc4/linux
Bug#328534: Reopening
On Wed, Oct 26, 2005 at 10:02:05AM +0200, Sven Luther wrote: On Tue, Oct 25, 2005 at 11:57:30PM -0700, Jurij Smakov wrote: reopen 328534 thanks This bug needs to be reopened in view of the new information. Apparently, our 2.6.12-10 kernel, which includes the backported fix for the dpt_i2o SCSI driver still oopses. Also, it has been reported that 2.6.13 that should include all the upstream fixes hangs during dpt_i2o initialization (see the previous message). What about 2.6.14-rc5 ? Jurij, could you send a link to or post the patch? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Wed, Oct 26, 2005 at 09:37:54AM +0200, Marco d'Itri wrote: On Oct 26, Horms [EMAIL PROTECTED] wrote: Just to clarify, udevd gets a bunch of events and tries to serialise them into modprobe calls, right? Do you think there There is no serialization, only some throttling (IIRC it tries to run up to 10 child processes in parallel). Ok, but it runs modprobe, not ismod, right? is any chance it might be calling modprobe out of order for some reason. The point is the dependencies are handled by modprobe, so the order in which udevd loads the modules at the top of the dependency tree is not relevant. True. As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so far I have not been able to reproduce the bug again (which may or may not be related, I need a few more reboots). Thanks. I'm not having any luck reproducing the problem at all. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Fri, Oct 21, 2005 at 04:54:35PM +0200, Marco d'Itri wrote: On Oct 21, Horms [EMAIL PROTECTED] wrote: I did a bit of a poke around this symbols problem. I puzzeled over it for a while. I began to wonder if it might be caused byudevsynthesize[1] which seems to be the major change between -2 and -4, and I completely failed in all my attempts to reproduce the problem. It's *exposed* by udevsynthesize because it makes udevd try to load in parallel a big number of modules at the same time. I expect that you should be able to reproduce the bug with: for m in $MODULES; do /sbin/modprobe $m ; done Just to clarify, udevd gets a bunch of events and tries to serialise them into modprobe calls, right? Do you think there is any chance it might be calling modprobe out of order for some reason. I then chatted it over with some people, and they suggested that it might actually be a problem with a bogus depmod run. No, it's not. I checked my modules.dep and it's correct, and anyway if it were broken loading the same modules with modprobe from the command line would not work. True Alternateively, its seems there is a high correlation between this problem and loading uhci_hcd. Providing lspci -vv might help a bit. Also 8250, but I can't see how this could be related to the hardware at all... All of this happens before the drivers are even initialised. Do not forget that the bug is not reliably reproducible, some days on my system may fail one of 8250, 8250_pnp, uhci_hcd or nothing at all. What I am wondering is, perhaps there are some modules that cause udevd to generate events in the wrong order. This would line up with your theory that the bug is probably in the kernel, though as I can't reproduce it, it is somewhat tricky to debug. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
I did a bit of a poke around this symbols problem. I puzzeled over it for a while. I began to wonder if it might be caused byudevsynthesize[1] which seems to be the major change between -2 and -4, and I completely failed in all my attempts to reproduce the problem. [1] http://marc.theaimsgroup.com/?t=11248247225r=1w=2 I then chatted it over with some people, and they suggested that it might actually be a problem with a bogus depmod run. Can people who are seeing this run depmod manually and see if the problem goes away? Alternateively, its seems there is a high correlation between this problem and loading uhci_hcd. Providing lspci -vv might help a bit. Also, what kind of usb devices do the people who are seeing this have plugged in. I tried with a few I found lying around the office, but to no avail. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333522: possible problem cause: wait4(-1)
On Thu, Oct 20, 2005 at 09:44:07AM +0200, Marco d'Itri wrote:
On Oct 20, Horms [EMAIL PROTECTED] wrote:
Could you please point me to the part of the code where udevd calls
modprobe and handles the subsequent SIGCHLD? That will be a good starting
poing
for further investigation.
run_program() in udev_utils_run.c, called from main in udev.c.
pid = fork();
switch(pid) {
...
default:
...
waitpid(pid, status, 0);
thanks
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333522: possible problem cause: wait4(-1)
On Wed, Oct 19, 2005 at 03:14:53PM +0200, Marco d'Itri wrote: reassign 333522 linux-2.6 thank On Oct 19, Rusty Russell [EMAIL PROTECTED] wrote: Right. It's not a modprobe bug then. Thanks, that makes sense. Oops... I did not read correctly Rusty's answer. If it's not a modprobe bug and not an udev bug (I checked udevd and it looks fine to me) then looks like it is a kernel bug. Could you please point me to the part of the code where udevd calls modprobe and handles the subsequent SIGCHLD? That will be a good starting poing for further investigation. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334113: linux-image-2.6.12-1-powerpc: kernel allows loadkeys to be used by any user, allowing for local root compromise
Thanks, that seems like a genuine problem, I am forwarding it upstream for consideration as it is not immediately apparent to me what the best solution is. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
On Sat, Oct 15, 2005 at 06:03:31PM +0200, Rudolf Polzer wrote: Package: linux-image-2.6.12-1-powerpc Version: 2.6.12-10 Severity: critical Tags: security Justification: root security hole The non-suid command loadkeys can be used by any local user having console access. It does not just apply to the current virtual console but to all virtual consoles and its effect persists even after logout. A proof of concept would be (^V, ^C etc. refer to key presses on the console): loadkeys keycode 15 = F23 string F23 = ^V^C^V^Mecho hello world^V^M ^D Then log out and let root login (in a computer pool, you can usually get an admin to log on as root on a console somehow). The next time he'll press TAB to complete a file name, he instead will run the shell command. Of course, the shell command could be more evil, e.g. add a line to /etc/passwd, clear the screen to make it less obvious, sync and write stuff to /dev/mem to cause a kernel crash so that most people would not suspect anything but a hardware fault. A demo exploit adding a line to the password file, clearing the screen and logging out exists in form of a shell script. As a solution, I propose that the loadkeys command (or more exactly, the kernel interface it uses) should be restricted to root and instead one could add a suid wrapper for loadkeys that only allows the system-wide keymaps to be loaded. The old behaviour could still be made selectable using a procfs file. If the last modification time of the manual page of loadkeys is true, this bug exists in the Linux kernel at least since 1997. However, the BUGS section of the manpage does not hint that the loadkeys command can even be used as a root compromise and not just for stuff like unbinding all keys. Plus, it might be good to have a way to disable chvt for non-root users. Using chvt, a malicious user could do the same thing in an X session: remap Backspace to another key, handle Ctrl-Alt-Backspace by chvt 1; chvt 7 (so the video mode switches) and showing a fake login manager on the X display. If chvt were not possible for mere mortals, the admin would be able to disable all possible video mode switching caused by X applications (like xrandr, xvidmode, dpms) in the xorg.conf file so that he finally knows: if Ctrl-Alt-Backspace caused video mode switching, the resulting login screen is genuine. Another solution would be a keymap-invariant non-remappable zap key combination with the functionality of Alt-SysRq-K - but on an X screen, it should tell the X server to exit instead of kill -9ing it so that the video mode gets restored. And it should be able to make a kernel support it without adding all of the other Magic SysRq Key features. Of course, it should lock the keymap until the user tells the system to unlock it again. Or, even better: a root login key. That is, something unremappable that causes a new VT to be created with a login prompt for root - and while this VT is active, the keymap should be locked to the system-wide standard keymap. Ideally, that root login key should also work from X and maybe even when the X server has crashed. Hi, I recently received the following message through the debian Bug tracker. http://bugs.debian.org/334113 In a nuthsell it raises concernes about the effects of giving users access to VT ioctls and outlines a potential attack using loadkeys to execute commands as root. I took a very brief look over it, and the concern does seem valid to me. Most of the VT ioctls are only garded by the following permissions, the ioctl in question, which I believe is KDSKBSENT, is no exception: drivers/char/vt_ioctl.c: vt_ioctl(): line 377 /* * To have permissions to do most of the vt ioctls, we either * have * to be the owner of the tty, or have CAP_SYS_TTY_CONFIG. */ perm = 0; if (current-signal-tty == tty || capable(CAP_SYS_TTY_CONFIG)) perm = 1; A simple fix for this might be just checking for capable(CAP_SYS_TTY_CONFIG) in do_kdgkb_ioctl(), which effects KDSKBSENT. This more restrictive approach is probably appropriate for many of the other ioctls that set VT parameters. However, the changes will still affect all consoles and be persistant after the user logs out of the console. It would seem more logical to have the state apply only to the current console, and only for the duration of the session. The latter could be handled in user-space if the ioctls were privelaged. But I suspect adding the former might be somewhat difficult. The same kind of issue also seems to be relevant to many of the other VT ioctls. I'm not really familiar enough with the code to comment more, though I am happy to code-up ideas if people can point me in the right direction. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334113: [Security] kernel allows loadkeys to be used by any user, allowing for local root compromise
On Mon, Oct 17, 2005 at 11:52:11PM -0700, Andrew Morton wrote:
Horms [EMAIL PROTECTED] wrote:
drivers/char/vt_ioctl.c: vt_ioctl(): line 377
/*
* To have permissions to do most of the vt ioctls, we either
* have
* to be the owner of the tty, or have CAP_SYS_TTY_CONFIG.
*/
perm = 0;
if (current-signal-tty == tty || capable(CAP_SYS_TTY_CONFIG))
perm = 1;
A simple fix for this might be just checking for
capable(CAP_SYS_TTY_CONFIG)
in do_kdgkb_ioctl(), which effects KDSKBSENT. This more restrictive
approach is probably appropriate for many of the other ioctls that set
VT parameters.
I briefly discussed this with Alan and he agreed that that's a reasonable
approach.
Thanks, thats pretty much what I had in mind. Though I would expect
some minor breakage, at least for people who expect nonsetuid loadkeys
to work. But then again, that is the whole point.
I'll stick the below in -mm, see what breaks.
--- devel/drivers/char/vt_ioctl.c~setkeys-needs-root 2005-10-17
23:50:37.0 -0700
+++ devel-akpm/drivers/char/vt_ioctl.c2005-10-17 23:51:43.0
-0700
@@ -192,6 +192,9 @@ do_kdgkb_ioctl(int cmd, struct kbsentry
int i, j, k;
int ret;
+ if (!capable(CAP_SYS_TTY_CONFIG))
+ return -EPERM;
+
kbs = kmalloc(sizeof(*kbs), GFP_KERNEL);
if (!kbs) {
ret = -ENOMEM;
_
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330446: Fixed in NMU of initrd-tools 0.1.83
On Sun, Oct 16, 2005 at 03:17:06PM -0700, Sven Luther wrote: tag 324351 + fixed tag 329614 + fixed tag 330446 + fixed tag 333857 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. For anyone who cares, this was not really an NMU, other than in the technical sense. It was made by Sven, who is a member of the Kernel Team, who maintains initrd-tools. I have added him and myself as uploaders to avoid any future confusion regarding uploads of initrd-tools made by Sven (or myself). -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 14 Oct 2005 07:50:57 + Source: initrd-tools Binary: initrd-tools Architecture: source all Version: 0.1.83 Distribution: unstable Urgency: low Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: Sven Luther [EMAIL PROTECTED] Description: initrd-tools - tools to create initrd image for prepackaged Linux kernel Closes: 324351 329614 330446 333857 Changes: initrd-tools (0.1.83) unstable; urgency=low . [ Simon Horman ] * Clarify naming of scripts that will be run. Thanks to Simon Schoar. (Closes: #324351) * Make sure that path to output image is always fully qualified, else an image with a relative will not end up where requested (closes: #329614) . [ dann frazier ] * Don't assume update-modules is available during postrm (closes: #330446) . [ Sven Luther ] * Added --supported-(host|target)-version support for the new post-2.6.13 ramdisk-tool policy. Added linux-ramdisk-tool virtual package too. (Closes: #333857) Files: bb2f5ea3f208f972649dfb5d1cac123e 644 utils optional initrd-tools_0.1.83.dsc eff2ad61dc7e18f607d541bd71a53dac 28815 utils optional initrd-tools_0.1.83.tar.gz dc7b11f6eb3cc3cf934c6639f1a1db3d 31728 utils optional initrd-tools_0.1.83_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDUs2o2WTeT3CRQaQRAhifAJ9jQVG+GwyAs7lGMD/dwllcAN/GmACfSEAA igkOcTRK7n9s9dQdA/xC2ew= =7/gM -END PGP SIGNATURE- -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279689: Same here
tag 279689 +pending tag 333067 +pending thanks On Wed, Oct 12, 2005 at 09:29:01PM -0700, Ian Eure wrote: Same problem as Rich reported. Old kernel was using the regular text console. System now boots with fbcon. It dies sometime after the network configuration with the endless scrolling rivafb_pan_display messages. It's been my experience that fbcon is slow and unreliable, and I don't think it should be the default. I'd at least like an option to /completely/ disable it - I don't want it loading any modules at all. Burning a netinst CD so I can get my system bootable again. Hi, this bug has been merged with 333067 and discussion there has resolved to disable the rivafb module, as it appears to be a quite broken. The discussion there also includes a suggested work around, to move rivafb.ko (or remove it), so it isn't loaded at boot (or any other time). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333067 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322273: pending bugs galore
tag 322273 +pending tag 328389 +pending tag 330353 +pending thanks These bugs are fixed for 2.6.8 in SVN and are pending release. #322273: CAN-2005-2456: XFRM array index buffer overflow #328389: CAN-2005-2800: memory leak in scsi procfs leads to local DoS #330353: kernel-source-2.6.8: CAN-2005-3053 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330329: 2.6.12-10 built on my sparc pbuilder
On Tue, Sep 27, 2005 at 11:32:29PM -0700, Blars Blarson wrote: linux-2.6 2.6.12-10 built fine on my sparc pbuilder. I think the build should be requeued, preferably on auric if it has more disk space available. Thanks for that information. I think Dannf was plaining to do a binary-upload. But if that doesn't pan out, how can we get the build requeued? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330329: linux-2.6: 2.6.12-10 FTBFS on sparc
Package: linux-2.6 Severity: serious Justification: no longer builds from source Seems like 2.6.12-10 fails to build on sparc http://buildd.debian.org/fetch.php?pkg=linux-2.6ver=2.6.12-10arch=sparcstamp=1127830883file=logas=raw LD sound/usb/usx2y/built-in.o CC net/socket.o CC net/802/p8023.o cc1: No such file or directory: opening dependency file net/802/.p8023.o.d make[6]: *** [net/802/p8023.o] Error 1 make[5]: *** [net/802] Error 2 make[4]: *** [net] Error 2 Curiously -6,-7,-8 and -10 all built on sparc http://buildd.debian.org/fetch.php?pkg=linux-2.6ver=2.6.12-10arch=sparcstamp=1127830883file=logas=raw I say curious, because -10 made ia64 and hppa changes Does anyone have any ideas? And if not, is there a box where I can play with building this? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-rc3 Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) (ignored: LC_ALL set to ja_JP.eucJP) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330157: paer.debian.org and kernel builds
Hi, We have a build problem with the kernel on hppa and I was hoping to use paer.debian.org to do some test builds. If there is a better machine please let me know. Otherwise, would it be possible to get the following build dependancies installed in the sid chroot? gcc-4.0-hppa64 module-init-tools kernel-package (= 9.005) transfig xmlto dh-kpatches (= 0.99.3) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330157: hppa build woe
tag 330157 +pending thanks I have fixed this in SVN by removing the spurious drivers/serial/serial_core.c.orig portion of hppa.patch. Kyle is doing a test build on hppa, and I will upload tomorrow if that goes to plan. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330157: linux-2.6: [hppa] FTBFS -- hppa patch doesn't apply cleanly.
On Mon, Sep 26, 2005 at 01:54:04PM +0200, Sven Luther wrote: So, i guess there is some uncleanliness in the serial_core.c hppa patch, or maybe someting else. Simon Horman mentioned that part of the hppa patch should be separated and rejoin the main debian patches instead of keeping such a huge hppa-specific patch, maybe this would be the best time to do this, or at least try to get that done for 2.6.13-1. Yes, I at a cursoary glance the hppa (and m68k) patches do seem to contain portions that could be put in the main patch-set. But I don't think that 2.6.12-10 is the time to do this, nor do I think there is any rush to do it. More to the point, I only took a cursoary look, so the patches may well be best left where they are, though perhaps broken out a bit - one of the best things our kernel packages have done over the past year is to be very good at breaking out patches to correlate to chanlog-entry level changes. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330214: kernel-image-2.6.8-2-686: kernel panic when using QUEUE target with iptables
On Mon, Sep 26, 2005 at 10:23:48PM +0300, Ilkka Pietikäinen wrote: Package: kernel-image-2.6.8-2-686 Severity: critical Justification: breaks unrelated software Our userspace software uses QUEUE target with iptables. We have reports from our customers that their debian systems are chrashing (with panics). With other distrubutions we have detected similar behaviour and it is fixed by applying the patch from https://lists.netfilter.org/pipermail/netfilter-devel/2005-July/020513.html This is a known problem in vanilla kernel and is already fixed. Thanks, I will look into gettting that into the next 2.6.8 release. -- Horms
Bug#330157: paer.debian.org and kernel builds
On Mon, Sep 26, 2005 at 10:27:56AM -0700, Matt Taggart wrote: Horms writes... We have a build problem with the kernel on hppa and I was hoping to use paer.debian.org to do some test builds. If there is a better machine please let me know. paer is the correct machine. Thanks Otherwise, would it be possible to get the following build dependancies installed in the sid chroot? gcc-4.0-hppa64 module-init-tools kernel-package (= 9.005) transfig xmlto dh-kpatches (= 0.99.3) Thanks, much appreciated. I'm using paer right now to verify 2.6.12-10 before upload, its been a while since 2.6.12 actually built on hppa, but I think we are close if not there. Thanks to Matthew Wilcox and Kyle McMartin and others who did the real work. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328707: partial patch
On Thu, Sep 22, 2005 at 08:10:10AM +0200, Joey Hess wrote: Here's the best patch I've been able to find for this so far. This is completely weird, any ideas why this hasn't shown up before? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328707: partial patch
On Thu, Sep 22, 2005 at 09:55:24AM +0200, Joey Hess wrote: Horms wrote: On Thu, Sep 22, 2005 at 08:10:10AM +0200, Joey Hess wrote: Here's the best patch I've been able to find for this so far. This is completely weird, any ideas why this hasn't shown up before? Apparently it's known breakage caused by the new binutils that I guess only just reached Debian in the past couple weeks. If you google for the error message you get several variants of the patch and a little bit of explanation. The patch isn't as partial as I thought, I'm a good way through a 2.4.27 compile now. Ok, that makes sense. Let me know if the build completes and if so I'll add it to the tree. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289690: cannot access some files with samba
On Tue, Sep 13, 2005 at 12:24:49PM -0700, J. William Campbell wrote: This bug can easily be produced by creating a zero-length file on the Windows XP system. Attempting to copy this empty file from XP to the Linux system will then produce this error. Unfortunately this is not the only way to produce the error, but zero-length files seem to always produce the error. Hi, could you please try the sarge backport of 2.6.12 to see if this problem has been resolved in those packages. http://packages.vergenet.net/testing/linux-2.6/ -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322500: libsnmp5: ABI change without SONAME change
On Fri, Sep 09, 2005 at 10:51:02AM +0200, Jochen Friedrich wrote: Hi Steve, The bug log at http://sourceforge.net/tracker/index.php?func=detailaid=1256697group_id=12694atid=112694 shows that upstream has issued an official update for the soname of libsnmp, available in patch form at http://sourceforge.net/tracker/index.php?func=detailaid=1282477group_id=12694atid=456380. It would be ideal if you could apply this patch to net-snmp and upload, so that the segfaults in packages depending on libsnmp can be fixed. I know :-). I'm currently preparing the package and hope to get it out today. Can someone advise me if heartbeat will need to be rebuilt against these new packages? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327123: acknowledged by developer (Re: Bug#327123: kernel-kbuild-2.6-3: FTBFS cloop-src with kernel-headers-2.6.8-2-k7 in testing)
On Thu, Sep 08, 2005 at 09:30:46AM +0200, Kars de Jong wrote: On wo, 2005-09-07 at 21:48 -0700, Debian Bug Tracking System wrote: On Wed, Sep 07, 2005 at 09:37:29PM +0200, Kars de Jong wrote: Package: kernel-kbuild-2.6-3 Version: 2.6.8-2 Severity: serious Justification: no longer builds from source Hi, kernel-kbuild-2.6-3 has been removed from testing and unstable, it is only intended for sarge, and will only compile in that environment. If you really need to use it, you might be able to make it work by using gcc-3.3 instead of gcc-4.0. 1) This package has not been removed from testing or unstable: Available versions: Stable 2.6.8-2 Testing 2.6.8-2 Unstable 2.6.8-2 Sorry, I made a mistake when I checked. Yes kernel-kbuild-2.6-3 indeed in testing and unstable. Though it is only used in conjucntion with the 2.6.11 kernel header packags, and they, along with kernel-kbuild-2.6-3 will be removed shortly. 2) I _AM_ using gcc-3.3 to compile. module-assistant automatically selects the right compiler. Also see the bug report: CC=gcc-3.3 /usr/bin/make install-module KBUILD_VERBOSE=1 KERNEL_DIR=/usr/src/kernel-headers-2.6.8-2-k7 INSTALL_MOD_PATH=/usr/src/modules/cloop/debian/cloop-module-2.6.8-2-k7 If you look at the log in the bug report you can see it is a missing kernel header, it has nothing to do with the compiler version used. Ok, I did take a closer look. To be honest I'm not sure what the relationship between the error that you report and kernel-kbuild-2.6-3 is. The irq_vectors.h question is included in kernel-headers-2.6.8-2-k7 (incidently that has been removed from testing/unstable, please use 2.6.12 instead). It seems that you need to add /usr/src/kernel-headers-2.6.8-2-k7/include/asm/mach-default/ (or /usr/src/linux-headers-2.6.12-1-k7/include/asm/mach-default/ as the case may be) to the include path, but I'm not entirely sure where that should be done. Actually, I'm not entirely sure what you mean by build cloop-src, could you be a little more specific so that the problem can be reproduced. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289690: cannot access some files with samba
On Thu, Sep 01, 2005 at 09:54:45AM +0200, Daniel Kabs wrote: Hello, this is my first comment on bugs.debian.org. I hope this is the correct way to add my 5 cent to it. Yes, indeed it is, thanks for the additional information. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Wed, Aug 31, 2005 at 01:59:26AM +0200, Marco d'Itri wrote: On Aug 31, Steve Langasek [EMAIL PROTECTED] wrote: If you aren't satisfied with the current solution, the answer is to figure out a better one rather than lamenting that no one else has. (I do have a This is where these threads usually end... With one of your terse one-liners? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325607: realtime-lsm: Module doesn't compile against 2.6.8-2-k7
On Mon, Aug 29, 2005 at 11:26:22PM +0200, Guenter Geiger wrote: On Mon, 29 Aug 2005, Nicholas Humfrey wrote: Package: realtime-lsm Version: 0.1.1-6 Severity: grave Justification: renders package unusable The 2.6.8-2 kernel (which is the default on sarge) does not have CONFIG_SECURITY_SELINUX enabled, which means it is not possible to use this module against the default stock kernel. Hmm, it used to compile, is there a reason why this is not enabled anymore ? Is there something I could do better. Obviously, with the current situation realtime-lsm has to go. From memory, that option was disabled in 2.6.8 because of performance concerns. In any case, whats done is done, and Sarge is most definately done. 2.6.8 is now in maintenance mode and is/has been removed from testing/unstable. If this is a sarge issue, I guess we are stuck with it. If you are looking at testing/unstable, then please use the kernels provided by the linux-2.6 source package (currently 2.6.12), which should have CONFIG_SECURITY_SELINUX (and other related options) enabled. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 01:46:49AM +0200, Marco d'Itri wrote: Package: udev,linux-2.6 Severity: grave udev = 0.060-1 and kernels = 2.6.12 should enter testing at the same time. If udev is first it will refuse to be upgraded (or install but disable itself on new installs), if the kernel is first some udev rules (at least the ones referencing sysfs attributes) will not work. Monitor the situation at: http://bjorn.haxx.se/debian/testing.pl?package=linux-2.6 http://bjorn.haxx.se/debian/testing.pl?package=udev and close this bug when both packages will be ready to enter testing at the same time. Can this be resolved by some dependancies and conflicts? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324591: kernel-source-2.4.27: FTBFS: Missing Build-Depends
tags 324591 +pending thanks On Mon, Aug 22, 2005 at 02:29:56PM -0700, Daniel Schepler wrote: Package: kernel-source-2.4.27 Severity: serious Version: 2.4.27-11 From my build log (reproduced using pbuilder in an i386 chroot): ... make[5]: Entering directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts' gcc-3.3 -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o docproc.o docproc.c make[5]: gcc-3.3: Command not found make[5]: *** [docproc.o] Error 127 make[5]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts' make[4]: *** [/tmp/buildd/kernel-source-2.4.27-2.4.27/scripts/docproc] Error 2 make[4]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27/Documentation/DocBook' make[3]: *** [sgmldocs] Error 2 make[3]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' make[2]: *** [real_stamp_doc] Error 2 make[2]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' make[1]: *** [stamp-doc] Error 2 make[1]: Leaving directory `/tmp/buildd/kernel-source-2.4.27-2.4.27' make: *** [binary-indep] Error 2 Thanks for bringing this to my attention, I have added gcc-3.3 as a build dependancy in SVN and it should appear in the next release. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322723: #322723 D-I: 'ip route add' fails w/ Network is unreachable
On Sun, Aug 21, 2005 at 01:14:45PM +0200, Frans Pop wrote: On Sunday 21 August 2005 03:56, Horms wrote: I've put the following in SVN, so this should be resolved in the next release. I noticed on IRC that you put a closes: #322723 in the changelog. I'm wondering if that is correct as I would say there still is a bad bug in gcc-4.0 causing the kernel to break when compiled with optimization. You may want to leave the bug open at reduced priority so that optimization may be reenabled when the problem in gcc-4.0 is fixed. For the same reason, maybe this bug should be cloned to gcc-4.0? Good point, though it might be best just to reassign it to gcc-4.0. I've seen this flag break stuff many time before - I actually wonder if it ever works as intended. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323224: [Linux-ha-dev] heartbeat package is broken on Debian Sid?
On Tue, Aug 16, 2005 at 11:04:34AM +0800, James Pan wrote: see below please. [EMAIL PROTECTED]:~# dpkg-query -l libsnmp5 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii libsnmp5 5.2.1.2-2 NET SNMP (Simple Network Management Protocol) Library [EMAIL PROTECTED]:~# apt-get install libstonith0 Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: libstonith0: Depends: libsnmp5 (= 5.1) but it is not going to be installed E: Broken packages Thanks, this was brought to my attention this morning and is being tracked as Debian Bug #323224. I've CCed that bug ([EMAIL PROTECTED]) on this mail. I'd appreciate if any folloups did the same. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323224 In a nutshell, there is a problem with libsnmp5 which is yet to be resolved. Once this happens, it will probably be neccessary (for me) to recompile and re-upload the heartbeat package. But I have been asked to hold off until libsnmp5 is in better shape, and I am doing just that. In the mean time, it should work fine in sarge, and likely works in testing too. I believe its just Sid aka unstable that is broken. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323224: libstonith0: uninstallable
On Mon, Aug 15, 2005 at 03:50:23PM -0700, Steve Langasek wrote: On Mon, Aug 15, 2005 at 05:00:42PM +0200, Steinar H. Gunderson wrote: Package: libstonith0 Version: 1.2.3-12 Severity: serious - libstonith0 depends on libsnmp5 (= 5.1). - libsnmp5 in sid conflicts with libstonith0 (= 1.2.3-12) libstonith0 should be rebuilt, and have a versioned dependency on the new libsnmp5. (libsnmp5 broke the ABI without changing the soname, thus the conflict; see #322500.) Please hold off on reuploading libstonith0; the manner in which the net-snmp maintainer chose to fix the ABI problem is not acceptable from a dependency management standpoint, and will require further changes that would in turn require libstonith0 to be reuploaded. Ok, holding off. Is there some way that I can get notification of when to rebuild. I have subscribed to #322500 (well tried to, we shall see if it works), so if more information goes there I should see it. Is there a better place to get this informatin? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323318: Array element has incomplete type
reassign 323318 kernel-source-2.4.27 merge 323318 320256 thanks On Mon, Aug 15, 2005 at 11:22:39AM -0700, Matt Kraai wrote: Package: kernel-headers-2.4.27-2 Version: 2.4.27-10 Severity: serious hostap-modules-i386 fails to build because a kernel header has an array type with an incomplete element type: /tmp/buildd/hostap-modules-i386-0.3.7/kernel-headers-2.4.27-2-386/include/asm/processor.h:75: error: array type has incomplete element type Hi, I believe that this is a duplcate of #320256. Please use gcc-3.3 to compile 2.4.27. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309308: [Secure-testing-team] Re: Bug#309308: kernel-image-2.6.8-2-686-smp: VLAN Oops fix for 2.6.8
On Fri, Aug 12, 2005 at 09:26:49AM +0200, Moritz Muehlenhoff wrote: Horms wrote: There is no public CVE assignment for this issue. If's it easily reproducable for non-root, it might account as a local DoS vulnerability. mii-tool's IOCTL is only allowed by root. The remote DoS comes from the fact that snmpd will call this IOCTL when it gets a request for the interface statistics. So it's exploitable via SNMP if the exploiter has access to the SNMP tree in question. (Which is not the default, if I recall correctly?) However, this means that cricket will bone the machine during the boot process, or soon after. I think thats a strong enough reason to tag it as a security fix, and thus include it in a kernel security update. Hi Horms, this is now CAN-2005-2548. Can you please add it to the changelog? Of course. Its in now. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321902: fails to rmmod usbnet
tags 321902 +wontfix thanks On Wed, Aug 10, 2005 at 11:22:39AM +0800, 肖盛文 Faris Xiao wrote: Andres Salomon wrote: On Tue, Aug 09, 2005 at 06:54:46PM +0900, Horms wrote: [...] rmmod usbnet The model usbnet can not be removed. Also the process which execute the command can not be finished,it consume the CPU 99% persistent,over and over.Even I can't use [...] If this does happen w/ 2.6.12, then a backtrace would be useful. Hit ctrl-alt-sysrq-t to get a dump of all processes on the system; that should include the rmmod process. The attachment cast.txt is the out put of ctrl-alt-sysrq-t. I can't execute ctrl-alt-sysrq-t under X Windows terminal,so I only get the last screen of the out put. Thanks, I assume this was from 2.6.8 I've taken another look at the problem, which the trace seems to indicate might be do_con_write(). But the changes to this code, and the usbnet code between 2.6.8 and 2.6.11 are quite extensive, and I have been unable to isolate the change. I am tagging this as wontfix, though cantfix might be a better discription. Perhaps somone will prove me wrong, but in the mean time, please use 2.6.12. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309308: [Secure-testing-team] Re: Bug#309308: kernel-image-2.6.8-2-686-smp: VLAN Oops fix for 2.6.8
On Thu, Aug 11, 2005 at 07:46:12PM +1000, Paul TBBle Hampson wrote: On Thu, Aug 11, 2005 at 11:04:17AM +0200, Moritz Muehlenhoff wrote: Horms wrote: below patch has been slurped into the Debian patches for 2.6.8, but the error posted looks like the same error I suffered when hitting this bug. Patch from http://lists.osdl.org/pipermail/bridge/2004-September/000638.html Cut and paste from the web archive, so spacing etc. may be boned. But it's a typo-only fix anyway, so easy enough to recreate. Thanks I have added this to SVN. Is this considered a security bug and if so does it have a CAN number? There is no public CVE assignment for this issue. If's it easily reproducable for non-root, it might account as a local DoS vulnerability. mii-tool's IOCTL is only allowed by root. The remote DoS comes from the fact that snmpd will call this IOCTL when it gets a request for the interface statistics. So it's exploitable via SNMP if the exploiter has access to the SNMP tree in question. (Which is not the default, if I recall correctly?) However, this means that cricket will bone the machine during the boot process, or soon after. I think thats a strong enough reason to tag it as a security fix, and thus include it in a kernel security update. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309308: kernel-image-2.6.8-2-686-smp: VLAN Oops fix for 2.6.8
tags +pending 309308 tags +patch 309308 thanks On Thu, Aug 11, 2005 at 11:42:54AM +1000, Paul TBBle Hampson wrote: Package: kernel-image-2.6.8-2-686-smp Followup-For: Bug #309308 Just noticed this bug in the testing-security list. I don't know if the below patch has been slurped into the Debian patches for 2.6.8, but the error posted looks like the same error I suffered when hitting this bug. Patch from http://lists.osdl.org/pipermail/bridge/2004-September/000638.html The patch was taken into 2.6.9-rc2, and the bug was in code introduced very late in the 2.6.8 cycle. (August 2004 I believe) diff -Nru a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c --- a/net/8021q/vlan_dev.c 2004-09-10 06:12:16 -07:00 +++ b/net/8021q/vlan_dev.c 2004-09-10 06:12:16 -07:00 @@ -772,7 +772,7 @@ case SIOCGMIIREG: case SIOCSMIIREG: if (real_dev-do_ioctl netif_device_present(real_dev)) - err = real_dev-do_ioctl(dev, ifrr, cmd); + err = real_dev-do_ioctl(real_dev, ifrr, cmd); break; case SIOCETHTOOL: Cut and paste from the web archive, so spacing etc. may be boned. But it's a typo-only fix anyway, so easy enough to recreate. Thanks I have added this to SVN. Is this considered a security bug and if so does it have a CAN number? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315968: kernel: usb-storage not working, system freeze
reopen 315968 thanks This bug is still valid for 2.6.8, so lets leave it here for now. At the very least we can use it to coodinate known problems in 2.6.8 -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321902: fails to rmmod usbnet
tag 321902 +moreinfo tag 321902 +upstream severity 321902 important thanks On Mon, Aug 08, 2005 at 01:30:48PM +0800, Ф Faris Xiao wrote: Package: kernel-image-2.6.8-2-686 Version: 2.6.8-16 Severity: grave Justification: renders package unusable I has a usb cable modem. My usb cable modem use kernel driver module usbnet. When I am using the modem,I execute the command: rmmod usbnet The model usbnet can not be removed. Also the process which execute the command can not be finished,it consume the CPU 99% persistent,over and over.Even I can't use kill -9 process id to terminal it ,only reboot the whole computer. The following is the dmesg output about my usb cable modem: Basically this means that the process is exceuting some code in the kernel, and that code is stuck, perhaps in a loop, perhaps waiting for a lock, but regardless stuck. You can't kill a process until it is back in user-space, and if this doesn't happen, you have to reboot :( Is it possible to get the dmsg output when this occurs? That might help track down the problem, but to be honest, its likely quite hard to narrow this down to a simple fix that is appropriate for inclusion in 2.6.8, which is now in maintenane mode for sarge. Your best option is probably to try linux-image-2.6.12-1-686 from unstable. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315968: kernel: usb-storage not working, system freeze
On Tue, Aug 09, 2005 at 03:11:20PM -0400, Andres Salomon wrote: reopen 315968 tags 315968 + sarge thanks I assume you meant to CC [EMAIL PROTECTED] :) Yes, unfortunately I often forget to do that. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322273: [CAN-2005-2456]: XFRM array index buffer overflow
tag kernel-source-2.6.8 +pending
thanks
On Wed, Aug 10, 2005 at 02:53:07PM +1000, Geoff Crompton wrote:
Package: kernel-source-2.6.8
Version: 2.6.8-16
Severity: critical
Justification: root security hole
SecurityFocus http://www.securityfocus.com/bid/14477 mentions an array index
buffer overflow.
In short, the suspect it can cause a denial of service attack, but
aren't sure whether or not it allows code execution.
Balaz Scheidler says at
http://www.mail-archive.com/netdev@vger.kernel.org/msg00520.html:
While reading through the xfrm code I've found a possible array
overflow in struct sock
He goes on to suggest some patches. However the patch at
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a4f1bac62564049ea4718c4624b0fadc9f597c84
is in the xfrm_user file instead.
I suspect this second patch that was commited will work, and checks the
direction earlier in the code flow than the original email from Balaz in
the first link. The xfrm_user patch is:
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1350,6 +1350,9 @@ static struct xfrm_policy *xfrm_compile_
if (nr XFRM_MAX_DEPTH)
return NULL;
+ if (p-dir XFRM_POLICY_OUT)
+ return NULL;
+
xp = xfrm_policy_alloc(GFP_KERNEL);
if (xp == NULL) {
*dir = -ENOBUFS;
Hi Geoff,
Thanks, we became aware of this problem last week
and it has been added to SVN for 2.4.27 (kernel-source-2.4.27),
2.6.8 (kernel-source-2.6.8) and 2.6.12 (linux-2.6)
The latter has been released. The former are taking a while
to get out the foor as we are still trying to iron out some
process issues relating to kernel updates for sarge.
For linux-2.6 it is bug #321401
On another note, when I'm looking at bugs like this, and I haven't found
them in the bug tracking database, should I be putting them against just
kernel-source-2.6.8, or against kernel-source-2.6.11 as well, or is
there a generic kernel-source-2.6 package?
Ok, this is pretty non-obvious, so thanks for asking.
Esentially we have three kernels that are being maintained right now,
and the packages you should log bugs against are kernel-source-2.4.27,
kernel-source-2.6.8 and linux-2.6 (which is 2.6.12 at the moment).
Older kernels, like 2.6.11 are currently being phased out and will
be removed from the Debian Archive shortly, so don't bother with them.
You can see what patches have been applied by inspecting the ChangeLog
in SVN.
http://svn.debian.org/wsvn/kernel/trunk/kernel/source/linux-2.6/debian/changelog?op=filerev=0sc=0
http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/changelog?op=filerev=0sc=0
http://svn.debian.org/wsvn/kernel/trunk/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/changelog?op=filerev=0sc=0
As for which package to log a bug against, or cretion of duplicate bugs.
To be honest it doesn't matter. If you email
debian-kernel@lists.debian.org, then you should get a response,
regardless of if you open a bug in the BTS or not.
CCing secure-testing-team@lists.alioth.debian.org if its a bug testing
and [EMAIL PROTECTED] if its a bug instable is also a good idea.
When we find problems, we just fix them. The BTS is really a bit to
noisy for us to use it to track bugs effectively. Obviously this
is a bit of a problem, but what I am trying to say is adding a bug
to the BTS just emails debian-kernel anyway, and security bugs
sent there are acted on. So my my advice is tho email the addresses
above, and if you want to open a bug, just open it against any
of the above packages that have the vulnerability.
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320256: (kernel-image-2.4.27-2-k6: FTBFS on its intended target) : more info
reassign 320256 kernel-source-2.4.27 tag 320256 +pending thanks On Thu, Jul 28, 2005 at 09:19:29AM +0200, Emmanuel Charpentier wrote: I tried to build this kernel on a newer PIV. This dos *not* build with gcc 4.0 or gcc 3.4, but *does* build with gcc 3.3 I'll try this on the target machine, and let you know. Thanks, I am aware of that problem and it has been fixed in SVN. However, 2.4 will likely be removed from unstable shortly. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320053: kernel-image-2.6.8-2-686: Installing it with sarge leads to failing at booting next time
reassign 298623 kernel-source-2.6.8 reassign 320053 kernel-source-2.6.8 severity 320053 normal merge 298623 320053 thanks On Wed, Jul 27, 2005 at 05:40:59PM +0200, stefan wrote: hi thx for your answer... i don't see why this bug is related to me... another developer just mailed me and showed me this bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298623 and this is exactly my problem g Yes, I think you are correct, I have merged these bugs accordingly. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319958: inkscape: fails to install (wrong dependencies)
On Tue, Jul 26, 2005 at 12:45:05AM +0200, Cyril Brulebois wrote:
Package: inkscape
Version: 0.41-5
Severity: grave
Tags: patch
Justification: renders package unusable
Hi!
When trying to install inkscape, it doesn't success due to dependency
problems:
inkscape: Dépend: libgc1 mais il n'est pas installable
Dépend: libglibmm-2.4-1 (= 2.6.1) mais ne sera pas installé
Dépend: libgtkmm-2.4-1 (= 2.6.0) mais ne sera pas installé
Dépend: libsigc++-2.0-0 (= 2.0.2) mais il n'est pas installable
E: Paquets défectueux
Rebuilding it 'as is' should be sufficient to refresh the dependencies (via
the ${shlibs:Depends} variable). I joined the diff between the official
dependencies and mine.
I can confirm that simply rebuilding the packages works fine here too.
I've put these up at http://debian.vergenet.net/testing/inkscape/
on the off chance they are useful to anyone. I'll delete them when
this bug gets closed.
--
Horms
Bug#318287: CAN-2005-2231 temporary file vulnerabilities
reopen 318287 1.2.3-11 didn't seem to make it into the archive for some reason - presumably because I mucked up the upload. I am going to resolve this ASAP. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317637: kernel-source-2.4.27: kernel compile fails :-(
On Sun, Jul 10, 2005 at 11:18:29AM +0100, George B. wrote: Package: kernel-source-2.4.27 Version: 2.4.27-10 Severity: grave Justification: renders package unusable Hello, I have just tried recompiling the kernel, to catch up with some security issues, but the compile fails. I am using: Hi, It looks a lot like you are trying to build this kernel with gcc-4.0. This will not work. Please use gcc-3.2. Also, if you think there are outstanding security issues with this kernel, pleaese file bugs against kernel-source-2.4.27, and include any references to CAN numbers, mailing list discusions and best of all patches, that you have. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317386: Package: kernel-image-2.4.27-2-686
On Thu, Jul 07, 2005 at 10:51:19PM -0500, Duane Meyer wrote: Package: kernel-image-2.4.27-2-686 Version: 2.4.27-10 Severity: grave Justification: causes non-serious data loss Jul 6 08:25:45 swr999 kernel: kernel BUG at page_alloc.c:144! Jul 6 08:25:45 swr999 kernel: invalid operand: Jul 6 08:25:45 swr999 kernel: CPU:0 Jul 6 08:25:45 swr999 kernel: EIP:0010:[__free_pages_ok+68/720] Not tainted Jul 6 08:25:45 swr999 kernel: EFLAGS: 00210282 Jul 6 08:25:45 swr999 kernel: eax: ebx: c101ef20 ecx: c025ecf0 edx: c025eb40 Jul 6 08:25:45 swr999 kernel: esi: c101ef20 edi: ebp: dda0bc54 esp: c160bf0c Jul 6 08:25:45 swr999 kernel: ds: 0018 es: 0018 ss: 0018 Jul 6 08:25:45 swr999 kernel: Process kswapd (pid: 4, stackpage=3Dc160b000) Jul 6 08:25:45 swr999 kernel: Stack: 0001 00200282 0003 cb5fa140 cb5fa140 cb5fa140 c101ef20 c014282c=20 Jul 6 08:25:45 swr999 kernel:cb5fa140 c101ef20 c025ec18 3e6b c0135557 c101ef20 01d0=20 Jul 6 08:25:45 swr999 kernel:0c7f 01d0 001f 0020 01d0 c025ec18 c025ec18 c013577d=20 Jul 6 08:25:45 swr999 kernel: Call Trace: [try_to_free_buffers+140/256] [shrink_cache+807/944] [shrink_caches+61/96] [try_to_free_pages_zone+98/256] [kswapd_balance_pgdat+102/176] Jul 6 08:25:45 swr999 kernel: [kswapd_balance+40/64] [kswapd+152/185] [rest_init+0/64] [arch_kernel_thread+46/64] [kswapd+0/185] Jul 6 08:25:45 swr999 kernel:=20 Jul 6 08:25:45 swr999 kernel: Code: 0f 0b 90 00 50 a0 23 c0 8b 35 50 b2 2c c0 89 d8 29 f0 c1 f8=20 That looks very unfun. Do you have any more information on this. Was the system under load at the time, do you have any crazy kernel modules loaded, does it happen every Tuesday at 4am, have you overcloced the CPU? That kind of thing. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-686 Locale: LANG=3DC, LC_CTYPE=3DC (charmap=3DANSI_X3.4-1968) Versions of packages kernel-image-2.4.27-2-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.81.1 tools to create initrd image f= or p ii modutils 2.4.26-1.2 Linux module utilities -- no debconf information -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: smbmount does not honor uid and gid options with 2.4 kernel
On Tue, Jun 07, 2005 at 07:44:25PM -0700, Steve Langasek wrote: On Tue, Jun 07, 2005 at 06:42:33PM +0900, Horms wrote: On Mon, Jun 06, 2005 at 04:19:28AM -0700, Steve Langasek wrote: reopen 310982 tags 310982 security thanks samba 3.0.14a-4 didn't make the cut for sarge, so this bug is still present in the release. That being the case, it would be far better to fix this bug in the kernel instead of in smbfs. Hi Steve, I'm kind of trying to read your mind here, but are you thinking of just making a kernel that doesn't do SMB_CAP_UNIX at all? I think the best answer is for the kernel to track whether uid,gid,fmask,dmask options were specified, and if so, to ignore the permission info sent by the CAP_UNIX-enabled server. That may require changes to the ioctl interface, though; I'd have to check again whether there's any distinction between not setting the option, and setting the option to 0. Sorry for being slack about this. I scraped together a few moments to look into this. parse_options() in fs/smbfs/inode.c seems to handle the options parsed to a mount, and it does indeed seem to differentiate betwen an unset option and an option set to 0. I'll poke a bit futher to find where to put your suggested hack, but I have to run now. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: smbmount does not honor uid and gid options with 2.4 kernel
On Wed, Jul 06, 2005 at 07:17:20PM +0900, Horms wrote:
On Tue, Jun 07, 2005 at 07:44:25PM -0700, Steve Langasek wrote:
On Tue, Jun 07, 2005 at 06:42:33PM +0900, Horms wrote:
On Mon, Jun 06, 2005 at 04:19:28AM -0700, Steve Langasek wrote:
reopen 310982
tags 310982 security
thanks
samba 3.0.14a-4 didn't make the cut for sarge, so this bug is still
present
in the release. That being the case, it would be far better to fix
this bug
in the kernel instead of in smbfs.
Hi Steve,
I'm kind of trying to read your mind here, but are you thinking
of just making a kernel that doesn't do SMB_CAP_UNIX at all?
I think the best answer is for the kernel to track whether
uid,gid,fmask,dmask options were specified, and if so, to ignore the
permission info sent by the CAP_UNIX-enabled server.
That may require changes to the ioctl interface, though; I'd have to check
again whether there's any distinction between not setting the option, and
setting the option to 0.
Sorry for being slack about this. I scraped together a few moments to
look into this. parse_options() in fs/smbfs/inode.c seems to handle
the options parsed to a mount, and it does indeed seem to differentiate
betwen an unset option and an option set to 0. I'll poke a bit futher
to find where to put your suggested hack, but I have to run now.
Hi all,
There has been a lot of disucssion of how to resolve this bug,
which can be found at the following URL.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310982
I am pretty detached from this discussion, though it seems
to me that there is no particularly good solution for Sarge.
But the idea of disabling the use of CAP_UNIX if uid,gid,fmask or dmask
are specified does make sense to me. I have gone ahead and coded this
up in the surprisingly simple patch which is attached.
Samba people, my main question is, can smb_newconn() be called before
server.mnt.flags is set? If so my patch is invalid.
--
Horms
diff -pru kernel-source-2.4.27.orig/include/linux/smb_mount.h
kernel-source-2.4.27/include/linux/smb_mount.h
--- kernel-source-2.4.27.orig/include/linux/smb_mount.h 2004-02-18
22:36:32.0 +0900
+++ kernel-source-2.4.27/include/linux/smb_mount.h 2005-07-07
11:27:51.0 +0900
@@ -37,7 +37,9 @@ struct smb_mount_data {
#define SMB_MOUNT_OLDATTR 0x0002 /* Use core getattr (Win 95 speedup) */
#define SMB_MOUNT_DIRATTR 0x0004 /* Use find_first for getattr */
#define SMB_MOUNT_CASE 0x0008 /* Be case sensitive */
-
+#define SMB_MOUNT_NO_CAP_UNIX 0x0010 /* Hack for Debian to disable
+ SMB_CAP_UNIX if uid, gid, fmask
+ or dmask are set. See Bug#310982 */
struct smb_mount_data_kernel {
int version;
diff -pru kernel-source-2.4.27.orig/fs/smbfs/inode.c
kernel-source-2.4.27/fs/smbfs/inode.c
--- kernel-source-2.4.27.orig/fs/smbfs/inode.c 2004-02-18 22:36:31.0
+0900
+++ kernel-source-2.4.27/fs/smbfs/inode.c 2005-07-07 10:50:56.0
+0900
@@ -286,10 +286,10 @@ static struct option opts[] = {
{ oldattr,SMB_MOUNT_OLDATTR, 1 },
{ dirattr,SMB_MOUNT_DIRATTR, 1 },
{ case, SMB_MOUNT_CASE, 1 },
- { uid,0, 'u' },
- { gid,0, 'g' },
- { file_mode, 0, 'f' },
- { dir_mode, 0, 'd' },
+ { uid,SMB_MOUNT_NO_CAP_UNIX, 'u' },
+ { gid,SMB_MOUNT_NO_CAP_UNIX, 'g' },
+ { file_mode, SMB_MOUNT_NO_CAP_UNIX, 'f' },
+ { dir_mode, SMB_MOUNT_NO_CAP_UNIX, 'd' },
{ iocharset, 0, 'i' },
{ codepage, 0, 'c' },
{ ttl,0, 't' },
diff -pru kernel-source-2.4.27.orig/fs/smbfs/proc.c
kernel-source-2.4.27/fs/smbfs/proc.c
--- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2005-05-19 19:29:38.0
+0900
+++ kernel-source-2.4.27/fs/smbfs/proc.c2005-07-07 10:49:35.0
+0900
@@ -916,7 +916,8 @@ smb_newconn(struct smb_sb_info *server,
VERBOSE(LFS enabled\n);
}
#ifndef CONFIG_SMB_UNIX
- server-opt.capabilities = ~SMB_CAP_UNIX;
+ if (!server-mnt.flags SMB_MOUNT_NO_CAP_UNIX)
+ server-opt.capabilities = ~SMB_CAP_UNIX;
#endif
if (server-opt.capabilities SMB_CAP_UNIX) {
struct inode *inode;
Bug#316476: kernel-source-2.6.11: Fails to boot since 2.6.11-4
On Fri, Jul 01, 2005 at 02:10:04AM -0400, Pascal Giard wrote: Package: kernel-source-2.6.11 Version: 2.6.11-4 Severity: critical Justification: breaks the whole system (Sorry if this is a dupe, i had filled it against kernel-image-2.6.11-amd64-generic). kernel-source-2.6.11 is probably a better place than kernel-image-2.6.11-amd64-generic, as it seems likely the bug is in the code, rather than the config. In either case, could you pick one, assign both the bugs to it, and merge the bugs (or alternatively close one). The BTS doesn't sport the kernel's split packaging very well, but it seems better to avoid duplicates. On the up side, as of 2.6.12, the packages will have a single source, and this problem will go away to some extent. Sorry I can't offer much help on the bug itself for now, hopefully someone else can. Since kernel-image-2.6.11-amd64-generic 2.6.11-4, the kernel-image won't boot. The first error message says something like: Can't load shared object file libc.so.6 The second error message says it can't find sda1. My hypothesis is that the necessary modules for my onboard SATA controller are no longer included in the initrd image. I HAVEN'T modified /etc/mkinitrd/mkinitrd.conf. I've a pretty common Asus K8V-X motherboard which SATA ctrler requires at least scsi_mod, sata_via and libata to work. Booting with the current kernel-image-2.6.8-amd64-generic image works fine. I'm happy i kept my very old image before upgrading 2.6.11!! -Pascal -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-11-amd64-generic Locale: LANG=fr_CA, LC_CTYPE=fr_CA (charmap=ISO-8859-1) -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315771: perdition: FTBFS: Not using -fPIC to make shared lib.
On Sun, Jun 26, 2005 at 12:22:11PM +0900, Horms wrote: On Sat, Jun 25, 2005 at 11:02:16PM +0200, Kurt Roeckx wrote: [snip] /build/buildd/perdition-1.17/perdition/db/daemon/libperditiondb_daemon_packet.a: could not read symbols: Bad value Note that the packet.c did not get build using libtool, while the rest did. libtool correctly set -fPIC to make the shared version for the other files that are getting linked in. Policy section 10.2 says that shared libs should be build using -fPIC and static should be build without it. Hi Kurt, This bit of code has been highly problematic forever. Thanks for bringing its still-broken state to my attention. I will have another go at rearanging the code. Any suggestions are more than welcome. Hi Kurt, I have tried a fresh approach to this problem, that is making the code in question a shared object. It is compiled with -fPIC as far as I can see. This change is included in the 1.17-2 packages that I have put in http://debian.vergenet.net/pending/perdition/ If you have a chance, could you test to see if these solve the problem that you are seeing. It would be nice to make sure it is resolved before uploading these to Debian.Org. Thanks -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315771: perdition: FTBFS: Not using -fPIC to make shared lib.
On Sat, Jun 25, 2005 at 11:02:16PM +0200, Kurt Roeckx wrote: Package: perdition Version: 1.17-1 Severity: serious Tags: sid Hi, Your package is is not using -fPIC to make a shared lib. This does not work on some arches, and results in your package failing to build: make[5]: Entering directory `/build/buildd/perdition-1.17/perdition/db/daemon' gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../ -I../../../perdition -I../../../libjain -DPERDITIONDB_BDB_SYSCONFDIR=\/etc/perdition\-g -O2 -c packet.c rm -f libperditiondb_daemon_packet.a ar cru libperditiondb_daemon_packet.a packet.o ranlib libperditiondb_daemon_packet.a [...] gcc -shared .libs/perditiondb_daemon.o .libs/unix_socket.o -ldb -L/build/buildd/perdition-1.17/perdition/db/daemon -lperditiondb_daemon_packet -Wl,-soname -Wl,libperditiondb_daemon.so.0 -o .libs/libperditiondb_daemon.so.0.0.0 -ldb -L/build/buildd/perdition-1.17/perdition/db/daemon -lperditiondb_daemon_packet /usr/bin/ld: /build/buildd/perdition-1.17/perdition/db/daemon/libperditiondb_da emon_packet.a(packet.o): relocation R_X86_64_32 can not be used when making a s hared object; recompile with -fPIC /build/buildd/perdition-1.17/perdition/db/daemon/libperditiondb_daemon_packet.a: could not read symbols: Bad value Note that the packet.c did not get build using libtool, while the rest did. libtool correctly set -fPIC to make the shared version for the other files that are getting linked in. Policy section 10.2 says that shared libs should be build using -fPIC and static should be build without it. Hi Kurt, This bit of code has been highly problematic forever. Thanks for bringing its still-broken state to my attention. I will have another go at rearanging the code. Any suggestions are more than welcome. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311357: kernel-image-2.6.8-2: via-rhine fails to reserve I/O region, no networking available
tag 311357 +pending thanks Hi, I think I have isolated the patch that caused this problem, I have put up some test 2.6.8 images that do not include the patch in question. http://debian.vergenet.net/testing/ -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311357: Upgrade of 386 version of the 2.6.8 kernel breaks via-rhine
On Tue, Jun 07, 2005 at 08:50:37AM -0700, Alan W. Irwin wrote: On 2005-06-07 17:48+0900 Horms wrote: On Sun, Jun 05, 2005 at 01:11:54PM +0200, Norbert Tretkowski wrote: severity 311357 grave thanks * Alan W. Irwin wrote: This is a confirmation of the bad problem with the via-rhine module for the latest version of the 386 version of the 2.6.8 kernel. Sounds like a RC bug, so I'm setting it's severity to grave. I upgraded today from kernel-image-2.6.8.2-386 version 2.6.8-13 to 2.6.8-16, and my network card (D-link 10/100 DFE-530TX) that is controlled by the via-rhine module immediately quit working Too bad this bug didn't get realized when -16 was in unstable... looks like it's too late to fix this for 3.1r0. True, there was some late minute package shiffling which meant that -16 ended up going straight into sarge. Unfortunately now we have this bug. A similar thing seems to have happened with 2.4.27 and some neftilter symbols. It partly my fault (in the sense that I uploaded the packages) and partly a process issue. I do appologise for any inconvenience and I'll try and get updates together over the next few days. But we have clearly missed the boat for 3.1r0. Hi Horms: Thanks for acknowledging the via-rhine problem that has gotten into 3.1r0. For Debian sarge users it sounds like you have plans to fix version 2.6.8-16 which is excellent. But until that happens, and for on-going Debian testing users like me what kernel 2.6 solution do you recommend for all those who require via-rhine for their networking? For example, do you (or anybody else paying attention to this bug thread) know whether the via-rhine problems also occur for kernel-image-2.6.11 (currently in unstable)? I haven't heard any reports that they occur in 2.6.11, and I imagine there are people using that combination, so if I was in your shoes I would try that. I do have a box with a VIA rhine card, I will fire it up and see if I can a) reproduce the problem in 2.6.8-16, b) if it goes away in 2.6.11-5 and c) get some fixes available for 2.6.8. But its not the D Link card in question, so I am not sure if I am in a position to test if a given kernel works. On a brighter note, I have been unable to reproduce the nefilter bug I mumbled about in my previous post, so that appears to have been a false alarm. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311357: Upgrade of 386 version of the 2.6.8 kernel breaks via-rhine
On Sun, Jun 05, 2005 at 01:11:54PM +0200, Norbert Tretkowski wrote: severity 311357 grave thanks * Alan W. Irwin wrote: This is a confirmation of the bad problem with the via-rhine module for the latest version of the 386 version of the 2.6.8 kernel. Sounds like a RC bug, so I'm setting it's severity to grave. I upgraded today from kernel-image-2.6.8.2-386 version 2.6.8-13 to 2.6.8-16, and my network card (D-link 10/100 DFE-530TX) that is controlled by the via-rhine module immediately quit working Too bad this bug didn't get realized when -16 was in unstable... looks like it's too late to fix this for 3.1r0. True, there was some late minute package shiffling which meant that -16 ended up going straight into sarge. Unfortunately now we have this bug. A similar thing seems to have happened with 2.4.27 and some neftilter symbols. It partly my fault (in the sense that I uploaded the packages) and partly a process issue. I do appologise for any inconvenience and I'll try and get updates together over the next few days. But we have clearly missed the boat for 3.1r0. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310982: smbmount does not honor uid and gid options with 2.4 kernel
On Mon, Jun 06, 2005 at 04:19:28AM -0700, Steve Langasek wrote: reopen 310982 tags 310982 security thanks samba 3.0.14a-4 didn't make the cut for sarge, so this bug is still present in the release. That being the case, it would be far better to fix this bug in the kernel instead of in smbfs. Hi Steve, I'm kind of trying to read your mind here, but are you thinking of just making a kernel that doesn't do SMB_CAP_UNIX at all? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308634: kernel-source-2.6.8: A locally exploitable flaw to gain root.
merge 308724 308634 thanks On Wed, May 11, 2005 at 07:40:15PM +0300, Samuli Suominen wrote: Package: kernel-source-2.6.8 Severity: grave Justification: user security hole A locally exploitable flaw has been found in the Linux ELF binary format loader's core dump function that allows local users to gain root privileges and also execute arbitrary code at kernel privilege level. Version: 2.2 up to and including 2.2.27-rc2, 2.4 up to and including 2.4.31-pre1, 2.6 up to and including 2.6.12-rc4 Exploit, and futher information: http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.12-rc4-optimized Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) On Wed, May 11, 2005 at 03:08:38PM -0400, Andres Salomon wrote: On Wed, 11 May 2005 19:40:15 +0300, Samuli Suominen wrote: Package: kernel-source-2.6.8 Severity: grave Justification: user security hole A locally exploitable flaw has been found in the Linux ELF binary format loader's core dump function that allows local users to gain root privileges and also execute arbitrary code at kernel privilege level. Version: 2.2 up to and including 2.2.27-rc2, 2.4 up to and including 2.4.31-pre1, 2.6 up to and including 2.6.12-rc4 Exploit, and futher information: http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt Rumor has it, this is CAN-2005-1263. I'll commit the patch (http://mouth.voxel.net/~dilinger/core_dump_vul.patch) to svn once I'm someplace that I can actually log in.. On Wed, May 11, 2005 at 08:59:18PM -0400, Justin Pryzby wrote: Package: kernel-source-2.6.8 Severity: grave Tags: security patch Justification: user security hole http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.9 The relevent changes for this CAN appear to be solely in ./fs/binfmt_elf.c. There is also a memset in ./drivers/char/drm/drm_ioctl.c which should probably be added, among lots of other should-be-fixed things. I am going to work on getting this fix into 2.6.8 and 2.4.27. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308639: kernel-build vs. kernel-headers splitted broken, headers unuseable
On Wed, May 11, 2005 at 07:09:34PM +0200, Eduard Bloch wrote: Package: kernel-build-2.6.8-powerpc Version: 2.6.8-12 Severity: grave Hello, I tried to understand your packaging scheme and IMO you do it _wrong_. a) kernel-build-KVERS on other architectures is a package with common files. Your packages seem to play the role of kernel-headers-KVERS packges from other architectures (unique files). b) even assuming that you confused the meaning of kernel-headers-KVERS SIONS=detect make -C Linux-2.6 KERNEL_SOURCES=/usr/src/kernel-build-2.6.8-powerpc KERNEL=linux-2.6.8-powerpc CC=gcc make[2]: Entering directory `/usr/src/modules/shfs/Linux-2.6' make -C /usr/src/kernel-build-2.6.8-powerpc SUBDIRS=/usr/src/modules/shfs/Linux-2.6 modules make[3]: Entering directory `/usr/src/kernel-build-2.6.8-powerpc' make[3]: *** No rule to make target `modules'. Stop. make[3]: Leaving directory `/usr/src/kernel-build-2.6.8-powerpc' make[2]: *** [default] Error 2 make[2]: Leaving directory `/usr/src/modules/shfs/Linux-2.6' make[1]: *** [binary-modules] Error 2 make[1]: Leaving directory `/usr/src/modules/shfs' make: *** [kdist_build] Error 2 So your package descriptions lie, it is not a working build system and I doubt that that it has ever been for anybody. I suggest a radical rework of the headers/kernel-build part to make it work similar to the i386 pendants. Tell me if you need assistance, I just got a PPC box to play with it. Hi, A fix is being worked on for this, though I am not sure if/when it will be able to go into Sarge as the kernels for that release are frozen. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308757: CAN-2005-1263: Linux kernel ELF core dump privilege elevation
tags 308757 + pending thanks On Thu, May 12, 2005 at 09:13:48AM +0200, Moritz Muehlenhoff wrote: Package: kernel-source-2.4.27 Version: unavailable; reported 2005-05-12 Severity: grave Tags: security patch Paul Starzetz has found another flaw in the Linux kernel that can be exploited to gain extended local privileges. Please see his detailed advisory at http://isec.pl/vulnerabilities/isec-0023-coredump.txt Greg Kroah-Hartman has posted a patch for 2.6, which should apply to 2.4 as well. It's attached. I have mangled this fix so it applies to 2.4.27 and committed it to SVN. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308855: CAN-2005-1263 (again)
reassign 308855 kernel-source-2.6.8 severity 308855 grave merge 308855 308724 308634 thanks Hi Adam, thanks for reporting this bug. We are already tracking it as 308724 and 308634 for 2.6.8 and a separate bug for 2.4.27. A fix is also pending for 2.6.11. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307900: kernel-image-2.6.8-2-386: This image, and maybe some others are easiably locally rootable. Exploit included.
reassign 307900 kernel-source-2.6.8 tag 307900 + pending tag 307900 + security thanks On Fri, May 06, 2005 at 12:02:44PM +0300, Samuli Suominen wrote: Package: kernel-image-2.6.8-2-386 Severity: critical Justification: breaks the whole system Proof of consept: http://www.frsirt.com/exploits/20050322.k-rad.c.php This would work on other NON-SMP kernels too. Makes kernel images unusable for multiuser system. The fix for this is in SVN and will be made available in the next release. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307900: acknowledged by developer (Fixed in kernel-source-2.6.8 2.6.8-15)
On Tue, May 10, 2005 at 12:57:43PM +0300, Samuli Suominen wrote: Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #307900: kernel-image-2.6.8-2-386: This image, and maybe some others are easiably locally rootable. Exploit included., which was filed against the kernel-source-2.6.8 package. It has been closed by one of the developers, namely Horms [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer, by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) Received: (at 307900-done) by bugs.debian.org; 10 May 2005 08:40:49 + Great, thanks! One question, this means kernel-images for Sarge will be compiled from fixed kernel-source? I don't beleive this code will make it into sarge - the kernel has actually been frozen for a while now because of process problams that in a nushell mean that updating the kernel delays the release by 2 months. But it should appear in the rc1 update release of sarge and/or secutiry updates. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302704: CAN-2005-0750: Possible local root exploit through insufficient range checking in af_bluetooth
tag 302704 +pending thanks On Sat, Apr 02, 2005 at 02:54:52PM +0200, Moritz Muehlenhoff wrote: Package: kernel-source-2.4.27 Severity: grave Tags: security Justification: user security hole CAN-2005-0750: Insufficient range checking in af_bluetooth allows local root exploit. This is the full advisory: http://lists.grok.org.uk/pipermail/full-disclosure/ attachments/20050327/3f128a09/adv1.pdf This has been fixed in 2.4.30rc3, a fix is available in Bitkeeper: http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED] Thanks, I have this fix in SVN. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302352: kernel-source-2.6.8: possible local DoS in AIO on PPC64 and IA64 (CAN-2005-0916)
Thanks, I will add this to SVN ASAP. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302352: kernel-source-2.6.8: possible local DoS in AIO on PPC64 and IA64 (CAN-2005-0916)
tag 30235 +pending thanks Thanks, I have added this fix to both kernel-source-2.6.8 and kernel-source-2.6.11 in SVN and it should appear in the next release. If someone has a chance to test the build for ppc and ia64 that would be great. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
