xdm-shadow (was Re: 1.3 installation report.)
Hi, Mark Eichin: > 2) the xdm shadow support doesn't fall back in any sane way, > and it's more than just dropping a check -- a bunch of code needs > rearrangement. (If you run xdm-shadow on a non-shadow system, you *lose*...) Well, I just did that with xbase-3.2-6: # mv /usr/X11R6/bin/xdm-shadow /usr/X11R6/bin/xdm I can switch back and forth between shadow and non-shadow passwords, and can login via xdm just fine. Nothing bad happened, my machine hasn't exploded yet, etc. :-) There was indeed a problem with XFree86-3.1.2 (xdm-shadow didn't work with non-shadow passwords), but not with 3.2 and higher. With 3.2 and 3.2A, the only thing that remains to be fixed is the Imakefile that still generates two separate xdm binaries. I reported this to the XFree86 upstream maintainers, and got a reply from David Dawes: "We've dealt with this finally, and it will be fixed in 3.3." So, I would appreciate if it could be fixed in the next Debian 1.3 xbase release. Just move that single binary... > I've never understood why the debian shadow code was so primitive. Not just Debian, and not just Linux - getspnam() is also used on several other systems, Solaris being one of them. Like many other UN*X things, it is not perfect, maybe it is even primitive, but it works and is standard. Most reasonably current, portable sources, already know about getspnam(). > Any reason why the classic "getpw* give you a password field if you've > got root" implementation isn't used? I can think of a few reasons > (avoiding coredumps in programs not actually needing passwords) but Another reason is that in the past some setuid root programs (chfn, chsh) used to get the passwd entry using getpwnam(), modify it, and write it back to /etc/passwd. Congratulations, you just unshadowed your system... Sure, they can (and should) be fixed, but I prefer to play it safe. Besides, there is more information in /etc/shadow than just the encrypted passwords, and that information (password aging) would be lost. The people at AT&T who added getspnam() to SVR4 a few years back could probably give a better answer to this question than I did. Of course this is a matter of personal opinion, but I for one consider getspnam() to be the "classic" shadow password implementation. (Some systems actually do the getpw* thing, but I think it is a little unsafe.) > they're kind of weak [and could be handled better by simply providing > a shadow_need_passwords() call to enable the feature...] Non-standard - there are already so many different shadow password implementations... Regards, Marek -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New ncpfs package
Hi, I noticed that the Debian ncpfs package (Netware client filesystem tools) is orphaned, and the version is very old. I needed a newer version, so I packaged ncpfs-2.0.10. It is available from ftp://ftp.ists.pwr.wroc.pl/pub/linux/debian-local/ Note that I'm not an official Debian maintainer - please feel free to upload this package for me. The old version may have some security holes in ncpmount, so it may be good idea to upload it to "stable" as well. It is also in the new source format. How does one become an official Debian maintainer these days? I heard that it is not as easy as it used to be... Marek -BEGIN PGP SIGNED MESSAGE- Format: 1.5 Date: Sun, 15 Jun 1997 11:38:23 +0200 Source: ncpfs Binary: ncpfs Architecture: source i386 Version: 2.0.10-1 Distribution: unstable Urgency: low Maintainer: Marek Michalkiewicz <[EMAIL PROTECTED]> Description: ncpfs - a NetWare client filesystem Changes: ncpfs (2.0.10-1) unstable; urgency=low . * Upstream upgrade, new maintainer, new source format. Files: 45af6b91b0607afabffbdf0ed0ba5a52 636 net extra ncpfs_2.0.10-1.dsc 6f3ba2451bae4bb272e60524f4463a65 158262 net extra ncpfs_2.0.10.orig.tar.gz af136ba18aba4155ee9a8446dae72982 2597 net extra ncpfs_2.0.10-1.diff.gz 88d74a6b8dd7fb4fd7a9e81d9cf317d3 126670 net extra ncpfs_2.0.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBM6QSShS8Z5KBPKcRAQHasQP/RNZM+W9Ahsej9aHzSAG6OPcZePKO+G68 1BoIlQ209RCIzPWD3HdcFD42HiHCN6ksNCi/fqb0DEPph0cMi1UODDFrEZJwZnMM zJZpsoZ7CiAbI4P48AAp7G63wxI1swIEzKRYuVy92ZXVsr5tRh5O4fH/wXiR++MG /vRfoSc44K8= =+qFv -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Bug#1505: setterm is missing
Package: miscutils I can't find the setterm program (distributed as part of util-linux) anywhere in the distribution (the output from "grep setterm Contents" is empty, and this program is not on my freshly installed, fairly complete Debian system at home). It is not currently part of any package, but I think it might be part of the "miscutils" package (or some other package - the decision is not up to me). This is the program used to set various terminal attributes, including some specific to Linux console, like screen blanking timeout. Not an essential package, but a sometimes useful one. If there a program which is part of the distribution and does the same thing but has a different name, please ignore this report (I am new to Debian - previously using Slackware for over a year now, but it has become too messy and difficult to upgrade, so I installed Debian just for fun after I got a new hard drive). Marek
Bug#1505: setterm is missing
Bruce Perens: > I think there was a copyright problem with "setterm" that caused us to > remove it from the distribution a long time ago. If I recall correctly, > it didn't allow distribution for a fee, which is of course essential to > our CD-ROM redistributors. Hmm, setterm is distributed on countless Slackware CD-ROMs at least... Aren't we too paranoid about copyrights? Now that I have read the source, it says that the "conditions of use, modification and redistribution are contained in the file COPYRIGHT that forms part of this distribution" but I can't find this file anywhere. Has anyone tried to contact the author (Gordon Irlam [EMAIL PROTECTED]) about this? From a quick test using EXPN it seems that his e-mail address is probably still valid even though setterm was written in 1990... Marek
Bug#1337: Improper use of sscanf in procps
The patch which replaces the %40c format with %39s sometimes doesn't do the right thing: if the command name contains whitespace, it will be truncated (according to the scanf man page, the %s format "matches a sequence of non-white-space characters"). I suggest to apply the patch below. BTW, this bug also sometimes causes strange output for zombie processes: the pid and uid fields containing garbage. After converting the strange pid value to hex and each byte to ASCII, this is "ie>\0". This is caused by strcat() adding " " to the string which is too long (not NUL- terminated) and overwriting other fields in the structure. Not good... Marek diff -urN procps-0.97.orig/snap.c procps-0.97/snap.c --- procps-0.97.orig/snap.c Sun Sep 25 19:46:21 1994 +++ procps-0.97/snap.c Thu Oct 19 21:33:56 1995 @@ -35,7 +35,8 @@ ; *tmp='\0'; /* Now we can parse these two strings separately */ -sscanf(S, "%d %40c", &P->pid, P->cmd); +memset(P->cmd, 0, sizeof(P->cmd); +sscanf(S, "%d %39c", &P->pid, P->cmd); /* sizeof(P->cmd) == 40 */ sscanf(tmp+1, "%c %d %d %d %d %d %u %u %u %u %u %d %d %d %d %d %d %u %u " "%d %u %u %u %u %u %u %u %u %d %d %d %d %u", &P->state, &P->ppid, &P->pgrp, &P->session, &P->tty, &P->tpgid,
Bug#1706: xterm sets wrong tty perms
Package: xbase Version: 3.1.2-4 The default tty permissions in xterm are still 622. They should be changed to 620 or 600 (depending what should be the default: mesg y or n), group tty. Marek
Bug#1353: tar has no manual page
I think we could use tar man page from Slackware. The only problem: it has no copyright on it. Is this the reason for not including it in Debian? Marek
Bug#1743: SEGV in "at" date parsing
Package: at Version: 2.8a-2 The at command sometimes has problems with date parsing which result in a SEGV. For example: $ at tomorrow Segmentation fault But if I try this as root, it works... Marek
Bug#1765: /etc/init.d/xdm (and xfs) still sources /etc/init.d/functions
Package: xbase Version: 3.1.2-4 The /etc/init.d/xdm (and xfs) scripts still source /etc/init.d/functions - known problem, just yet another package to fix... Marek
Bug#1866: xwpe should depend on xcompat
Package: xwpe Version: 1.4.1-1 xwpe requires old X library (libX11.so.3) which is in the xcompat package. But xwpe does not "depend" on xcompat. Marek
Bug#1656: etc/ntp.drift should be somewhere in /var (FSSTND)
Andrew Howell: > Does anyone have any suggestions for this? Should I leave ntp.drift in > /etc or move it to /var/run or /var/lib/xntp? ... or /var/log/xntp - xntpd can generate some statistics logs if this feature is enabled in the config file, so a separate directory might be a good idea. Marek
Bug#1883: "compress" missing?
Package: base? gzip? I can't find the "compress" program on the system. I know, gzip is better, and can decompress *.Z files, but can't create *.Z files if I want to give something compressed to someone who doesn't have gzip (many non-Linux systems come with "compress" but not "gzip"). Source can be found for example in the FreeBSD distribution, and is under the standard BSD copyright which shouldn't be a problem for us... Marek
Bug#1883: compress" missing?
as far as licensing fees go. this includes 'arc', 'stuffit', and other commercial wrappers for 'compress'. yet they are signing up licensees for hardware chips. hewlett-packard supposedly has an active vlsi project, and unisys has board-level lzw-based tape controllers. (to build lzw into a disk controller would be strange, as you'd have to build in a filesystem too!) it's byzantine that unisys is in a tiff with hp regarding the patents, after discovering some sort of "compress" button on some hp terminal product. why? well, professor abraham lempel jumped from being department chairman of computer science at technion in israel to sperry (where he got the first patent), but then to work at hewlett-packard on sabbatical. the second welch patent is only weakly derivative of the first, so they want chip licenses and hp relented. however, everyone agrees something like the current unix implementation is the way to go with software, so hp (and ucb) long ago asked spencer thomas and i to sign off on copyright permission (although they didn't need to, it being pd). lempel, hp, and unisys grumbles they can't make money off the software since a good free implementation (not the best -- i have more ideas!) escaped via usenet. (lempel's own pascal code was apparently horribly slow.) i don't follow the ibm 'arc' legal bickering; my impression is that the pc folks are making money off the archiver/wrapper look/feel of the thing [if ms-dos can be said to have a look and feel]. now where is telebit with the compress firmware? in a limbo netherworld, probably, with sperry still welcoming outfits to sign patent licenses, a common tactic to bring other small fry into the fold. the guy who crammed 12-bit compess into the modem there left. also what is transpiring with 'compress' and sys 5 rel 4? beats me, but if sperry got a hold of them on these issues, at&t would likely re-implement another algorithm if they thought 'compress' infringes. needful to say, i don't think it does after the abovementioned legal conversation. my own beliefs on whether algorithms should be patentable at all change with the weather. if the courts finally nail down From <@mongo.pixar.com:[EMAIL PROTECTED]> Wed Nov 22 07:19:04 1995 Received: from mongo.pixar.com (mongo.pixar.com [138.72.50.60]) by bugs.cps.cmich.edu (8.6.12/8.6.9) with ESMTP id HAA05993 for <[EMAIL PROTECTED]>; Wed, 22 Nov 1995 07:19:03 -0500 Received: by mongo.pixar.com (8.7.1) id EAA12128; Wed, 22 Nov 1995 04:18:22 -0800 (PST) Old-Return-Path: <[EMAIL PROTECTED]> Subject: Bug#1656: etc/ntp.drift should be somewhere in /var (FSSTND) Reply-To: Marek Michalkiewicz <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Resent-From: Marek Michalkiewicz <[EMAIL PROTECTED]> Resent-To: [EMAIL PROTECTED] Resent-Date: Wed, 22 Nov 1995 12:18:04 GMT Resent-Message-Id: <[EMAIL PROTECTED]> X-Debian-Pr-Package: xntp From: Marek Michalkiewicz <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Andrew Howell) Date: Wed, 22 Nov 1995 13:09:38 +0100 (MET) Cc: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> from "Andrew Howell" at Nov 22, 95 09:34:53 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text X-Mailing-List: <[EMAIL PROTECTED]> archive/latest/7612 X-Loop: [EMAIL PROTECTED] Precedence: list Resent-Sender: [EMAIL PROTECTED] Andrew Howell: > There is already a /var/log/ntpstats directory, but I don't think it's > really the right place for it, it's not really a log file. Unless someone > really objects I think I'll just leave it in /etc According to fsstnd-1.2, "application state information" (I think ntp.drift is such a file) belongs in /var/lib. So I suggest /var/lib/ntp/ntp.drift or something like this. I don't really object to /etc but we are supposed to conform to fsstnd... Regards, Marek
Bug#1883: compress" missing?
Bruce Perens: > I was sort of hoping that compress would be replaced by "gzip" throughout > the world, and thus we would not have to deal with its hassles. That would be the case if gzip was in the public domain, but it is under the GPL which may be too restrictive for commercial UNIX vendors... Besides, someone had to use compress to produce gzip-1.2.4.tar.Z :-). > I don't think anyone would object to your distributing certain > contributed packages from outside the US. If you'd like to do that for > compress, please package it up and do so. After the patent matter, the > secondary factor is availability of a maintainer for the package. It needs not be distributed from outside the US (it's not crypto stuff), anyone can get it from Slackware or FreeBSD (ftp.cdrom.com for example). compress is very old and stable, so it shouldn't be much problem to maintain it... But that was not my point. I think in this case we should ignore the patent issue like everyone else does (other Linux distributions, FreeBSD, commercial UNIX vendors). I can maintain compress if you agree to put it in the standard distribution. People who buy a CD often don't have Internet access (so they can't just download a few missing "non-free" packages) and they expect a reasonably complete system. If the system is missing basic commands like compress, next time they will buy Slackware or FreeBSD instead... It is not possible to build a completely "free" system - as you know, the bin86 package is "for personal use only" (or some such), and it is essential to build the kernel. I think compress should be another such exception - it is an essential package, like gzip. Marek
Bug#1914: general protection in unix_proto_connect
Package: image Version: 1.2.13-4 Already reported as xdm problem (Bug#1690), but sounds like a kernel bug to me. I have never seen it before, and I have seen it several times on Debian systems only. It may be that gcc-2.6.3 generates some bad code... (I never had any problems with Linux 1.2.13 compiled by old good 2.5.8.) Or maybe just some Debian-specific X setup triggers the bug. This happens with the latest image-1.2.13-5 too (numbers differ slightly). Marek general protection: EIP:0010:00148afd EFLAGS: 00010206 eax: 6e6f632d ebx: 001fd2e8 ecx: 0072bdd0 edx: 00678000 esi: 74d4 edi: 74d4 ebp: 0072be8c esp: 0072be00 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process xdm (pid: 190, process nr: 15, stackpage=0072b000) Stack: 7460 74d4 b78c 0013 001119ce 0072be1c 002422a0 742f0001 2e2f706d 2d313158 78696e75 0030582f 0117 00205174 0018 0018 002b 0003 0004 1000 003165a0 0202 1000 Call Trace: 001119ce 0012a2cc 0012a674 00120637 00134291 00135250 00120f3f 001283c7 001284ab 00134363 00120637 00120637 00135b04 00110751 Code: ff 00 8b 94 24 00 01 00 00 8b 42 10 8b 72 14 8b 7e 10 89 b8 Using `System.map' to map addresses to symbols. >>EIP: 148afd <_unix_proto_connect+17d/1b0> Trace: 1119ce <_IRQ0_interrupt+56/80> Trace: 12a2cc <_check_aligned+100/140> Trace: 12a674 <_bread_page+58/190> Trace: 120637 <_verify_area+27/1a0> Trace: 134291 <_move_addr_to_kernel+39/70> Trace: 135250 <_sock_connect+108/130> Trace: 120f3f <_do_no_page+35f/3e0> Trace: 1283c7 <_put_last_free+b/30> Trace: 1284ab <_get_empty_filp+3f/80> Trace: 134363 <_get_fd+b/c0> Trace: 120637 <_verify_area+27/1a0> Trace: 120637 <_verify_area+27/1a0> Trace: 135b04 <_sys_socketcall+10c/430> Trace: 110751 <_system_call+59/a0> Code: 148afd <_unix_proto_connect+17d/1b0> incl (%eax) Code: 148aff <_unix_proto_connect+17f/1b0> movl 0x100(%esp,1),%edx Code: 148b06 <_unix_proto_connect+186/1b0> movl 0x10(%edx),%eax Code: 148b09 <_unix_proto_connect+189/1b0> movl 0x14(%edx),%esi Code: 148b0c <_unix_proto_connect+18c/1b0> movl 0x10(%esi),%edi Code: 148b0f <_unix_proto_connect+18f/1b0> movl %edi,0x90909000(%eax)
Bug#1657: acknowledged by developer (was: Sendmail uses flock instead of fcntl and is setgid root) (fwd)
> From: [EMAIL PROTECTED] (Ian Jackson) > Responsibility for it has been taken by one of the developers, namely > Anders Chrigstrom <[EMAIL PROTECTED]>. > > You should be hearing from them with a substantive response shortly, if > you have not already done so. If not, please contact them directly, OK, I don't hear from you, so... Just a small additional suggestion: 8.7.2 is out - while you are at it, consider upgrading to the latest version. I haven't read the release notes yet, but I'm sure it has some security fixes, as usual :-). Marek
Bug#2069: GNU last doesn't use ut_addr
Package: last Version: 5-12 The GNU version of last doesn't make use of the ut_addr utmp field which is supposed to contain the IP address for remote logins. The size of ut_host (16 chars) is too small and host names are often truncated. The IP address is the only reliable way to identify the remote host. The BSD-derived last from the current util-linux supports ut_addr. The remote address is stored in network byte order. It is currently not reliable either (login does a hostname lookup on the name passed after the -h flag) but I have a working patch for telnetd/rlogind to create an utmp entry for login (ut_addr filled in with the real remote IP address from getpeername, avoiding one hostname lookup). I will make this patch available soon, after some testing. BTW, it is probably too late to change "struct utmp" (more room for host namei, tty) - do we need the SVR4 utmpx thing? Marek
Bug#2070: /etc/issue and /etc/issue.net
Package: (base) The default /etc/issue and /etc/issue.net files contain the copyright notice. The /etc/motd file contains another copyright notice. I know copyrights are very important, but I think only one (/etc/motd) should be enough for most users :-). It would be more useful to put the OS/hostname/tty in /etc/issue* and put the copyright notices only in /etc/motd. This is what other Unices seem to do, as set up by default. Below is an example of how /etc/issue.net might look like (/etc/issue is similar but uses different escape characters). Note that the name Debian GNU/Linux (or Linux-based GNU system) isn't fair - a lot of code is from MIT (X11) and BSD (most networking programs) and they deserve some credit, too (or simply call it Debian Linux, everyone will know it is really GNU/MIT/BSD/Linux anyway). == Debian GNU/MIT/BSD/Linux 2.0R9 (%h) (%t) == Sorry for being picky about such details, after all everyone can put whatever they like in their /etc/issue* and /etc/motd... One real problem that would be nice to fix while we are at it: change the getty /etc/issue escape characters to match those used in /etc/issue.net, and change telnetd to display /etc/issue if /etc/issue.net is not present. Currently /etc/issue.net is a link to /etc/issue, but they are not really compatible because of different escape characters. Happy New Year to everyone! Marek
Bug#2069: GNU last doesn't use ut_addr
[EMAIL PROTECTED]: > I have reported this to the upstream maintainer. He promised me new acct code > (last is part of acct) about six months ago, so don't hold your breath. How about using last from util-linux? It has the standard BSD copyright, there are no patent issues that I know of, it knows about ut_addr, and even comes with a man page :-). Is the GNU last better? Why? Regards, Marek
Bug#2091: creating packages requires root privileges
Package: dpkg To create a binary *.deb package, root privileges are required. This is because you must create a complete directory structure with proper ownerships and permissions first, and then use dpkg-deb to create a package from it. But this should't really be necessary. A tar file is a tar file, and you can set any permissions inside it if you can write to it. The only thing that is necessary is a program to set permissions inside tar files. Another idea: unpack everything with mode 000 root.root (just because I am paranoid and to easily see failed installation, such permissions are rather unusual), and set all permissions correctly in postinst. This has the advantage that if permissions ever get messed up, they can be restored quickly without reinstalling the entire package. There is a package we could use for that, called fixperms (it is on sunsite). It can set and verify permissions using a text file where permissions are stored. It is GPLed, and the documentation even says that it is part of Debian - but I can't find it anywhere in the current distribution. Marek
Bug#2091: creating packages requires root privileges
> If you're creating a Debian package you need to be root on the system > you're going to install it on to test it. Even if you're using some > shared environment in which you don't have root on the main > development machine, is it really that problematic to make the > `binary' target on the test machine? It isn't _that_ problematic, but it is inconvenient, and technically not necessary. It isn't that problematic to transfer a few files using FTP, but it is often a lot more convenient to use NFS :-). Besides, it is generally recommended to do most things as an ordinary user, and use root only if really necessary. > A tool which could adjust permissions and ownership of the contents of > a tar file shouldn't be hard to write; you'd still have to get the tar > file back into the deb archive, of course. Or modify dpkg-deb to read a file (part of the source package) which specifies permissions of all files, and modify the intermediate tar archive while creating the package. I'm not sure about dpkg internals... Even if there is no intermediate tar file (output from tar is piped to gzip), it should still be possible to write a filter that reads a tar archive from stdin, changes the permissions to these specifed in the permissions file, and writes the modified tar archive to stdout (pipe to gzip in this case). Tar files are, by their nature (tape archive), sequential - no random read/write access should be required to do this. The package-specific permissions file could also be installed somewhere in /var/lib/dpkg/... and later used to verify that the permissions are correct, and fix them without reinstalling if they ever get messed up. Probably the biggest problem: find someone to write the program to change permissions inside tar files. Any tar file format experts out there? Marek
Re: Entry for the Distribution-HOWTO
Hi, > different sources and systems. Non-free packages and optional > support for shadow passwords are also available, making Debian a It might be a good idea to call the support for shadow passwords "experimental" or "beta" just to be safe (not all packages support them yet). I'll try to help to make it fully working and better integrated with the rest of Debian for the next release. Also, mentioning non-free packages and shadow passwords in one sentence might suggest to someone that shadow passwords are still non-free... I'd suggest something like the following: Optional support for shadow passwords is available, although it should be considered experimental in the 1.1 release. (and then write something about non-free packages) Regards, Marek
Bug#3320: Kernel oops - problem with APM BIOS?
Package: (bootdisk) Version: 1996_6_16 APM support is enabled in the 2.0 kernel on this bootdisk. Some "green" motherboards have problems with this, resulting in kernel oops every time during kernel startup (before mounting the root filesystem). Turning off power management in BIOS setup doesn't change anything - the buggy APM BIOS is still there. The machine has a 486DX2-66 "green" motherboard with Phoenix BIOS (more details on request). Another machine (with Award BIOS) works fine. The 1.2.13 kernel from 0.93R6 boots fine (because it has no APM support). The EIP value from the oops looks rather strange (2045:[]), but call trace suggests a problem with APM. The startup messages (may be inaccurate - they had to be written down manually): APM BIOS version 1.0 Flags 0x0b (Driver version 1.2) Entry f000:dbdf cseg16 f000 dseg 40 AC unknown, battery status unknown, battery life unknown Ramdisk ... hda: ST3660A, 520MB ... hdb: WDC AC280M, 81MB ... ... other messages ... FDC 0 is an 8272A. Unable to handle kernel NULL pointer dereference at virtual address c4ed current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = 00102067 *pte = 0027 Oops: CPU: 0 EIP: 2045:[ ] EFLAGS: 00010012 eax: 0016 ebx:00173700 ecx: edx: esi: 0020b838 edi:0016 ebp:7e38 esp:7e30 ds: 2050 es: fs: gs: ss:0018 Process swapper (pid: 1, process nr: 1, stackpage=7000) Stack: [snipped, was too much to write down] Call Trace: 001731fe - apm_get_event 00110018 - wake_up_interruptible 00173700 - do_apm_timer 00173579 - get_event 00173645 - check_events 00173700 - do_apm_timer 00173774 - do_apm_timer 00110834 - timer_bh 00115ec7 - do_bottom_half 0010a40b - handle_bottom_half Aiee, killing interrupt handler This problem makes it impossible to install the system on that particular machine. I'd suggest to disable APM support in the default installation kernels - it's not very important to be "green" during installation, users who need APM can recompile the kernel later, and APM code causes some kernel bloat too (RAM is cheap now, but anyway - has anyone tried if it's still possible to install Debian on machines with only 4MB of RAM?). Ideally, it should be possible to enable/disable APM support using boot time parameters. Currently the only way to disable APM is to recompile the kernel, which may be difficult if you don't have a working system first... Marek
Re: Keeping non-free separate
Buddha Buck: > Pine requires explicit permission for redistribution by for-profit > organisations, which means that Bruce can put it on his CD-ROMs, > Software in the Public Interest (Debian) can put it on their CD-ROMs, > but Yggdrisil or SSC (Linux Journal) can't. That's too unfree to not > be in non-free. We probably should ask the Pine developers on this one. It could well be free - quoted from /usr/doc/copyright/pine: [...] Re-distribution by for-profit organizations requires permission from the University of Washington. The above permissions are hereby granted, provided that the Pine and Pico copyright and trademark notices appear in all copies and that both the above copyright notice and this permission notice appear in supporting documentation, and that the name of the University of Washington not be used in advertising or publicity pertaining to distribution of the software without specific, prior written permission. [...] So as long as the notices appear in all copies (they do - all copies of the package contain /usr/doc/copyright/pine), and we don't use the name of the University of Washington in advertising (similar restrictions exist in BSD copyrights, probably no problem for us), it should be OK for Debian to distribute Pine(tm). Or am I missing something? > XV is shareware, and can't be bundled with "any product". While XV is > fairly liberal with its copying policy, it is non-free. I believe that > Bruce could bundle it on his CD, but I could be wrong. XV also > contains code for LZW compression (to support GIF), and that is > potentially effected by patent restrictions. I think we should ask the author for permission to distribute xv. It's probably not hard to get one as both Red Hat and Slackware can distribute xv. It's shareware, but free for personal use, and it comes with source. As for LZW, I think only compression is patented (decompression is not), so it should be OK to use xv to view GIF images, even if you are in the US... > Zip isn't allowed for commercial distribution (but bundling with > commercial software is OK, with restrictions), and it is unclear if > modification and subsequent redistribution is allowed. As long as due > care was taken, it could be shipped on CD-ROM. A few months ago I asked the authors of zip/unzip about this, and received a reply that they have no problems with us distributing their software as part of the Debian system. Or do we need this in writing? :-) (Again, zip and unzip are part of Red Hat and Slackware.) Thanks, Marek
Re: Keeping non-free separate
Bruce Perens: > Yes, I know. I'm thinking about how Debian should be differentiating itself > from the commercial Linux distributions. One way would be for the system to Debian is already differentiating itself from them - by its open development by volunteers, availability of the current development version (not only releases every few months), public bug tracking system, and powerful packaging system. I think this is fine as is, there is no need to differentiate itself more than that. > be _entirely_ free software, since they are all picking up commercial > software on their CDs. I have previously been a champion of the non-free > software in Debian, but I am re-thinking my position on it. I can't speak for all Debian users, of course, but I think most of them, like me, are probably interested more in a useful system and less in political goals like having 100% (not 99%) free software. Let's differentiate ourselves a little from the FSF too. Don't get me wrong, they make a lot of good free software which I use every day and I recognize their work, but I think too much politics is not good. I call my system "Linux", not "Lignux" :-). As long as most software is free, I don't mind a few shareware programs (distributed with permission from the authors, of course) included in the distribution. If I don't use them, I don't have to pay for them, and some of them are free for personal use (which is probably the case for most Debian users anyway). Thanks, Marek
Bug#4331: [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp (fwd)
Package: wu-ftpd
Version: 2.4-23
I don't know the exploit, but tar in the anon ftp area is the
same as the normal one, so I think Debian systems may have this
problem too. Two messages from the linux-security list (the
second one includes a patch for tar - only for anon ftp, not
for the normal one!) are attached below.
Marek
From: Elliot Lee <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp
Date: Mon, 19 Aug 1996 18:57:03 -0400 (EDT)
-BEGIN PGP SIGNED MESSAGE-
There is a security hole in the anonftp package included with all versions
of Red Hat Linux that allows an anonymous FTP user to execute arbitrary
commands in the chroot FTP environment. Due to some options in GNU tar
that are enabled by default, any program that exists (or can be uploaded
to) an FTP server can be run.
Severity is limited due to the chroot environment, but the problem still
needs to be addressed.
Updates are available on ftp.redhat.com now.
If you are using a version prior to 3.0.3, an upgrade is recommended to
solve other security holes.
If you are using 3.0.3 on the Intel, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/i386/updates/RPMS/anonftp-2.0-2.i386.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.3 on the Alpha, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/axp/updates/RPMS/anonftp-2.0-2.axp.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.4 (Rembrandt BETA) on the Intel, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/i386/updates/RPMS/anonftp-2.2-2.i386.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.4 (Rembrandt BETA) on the Sparc, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/sparc/updates/RPMS/anonftp-2.2-2.sparc.rpm
and install it using 'rpm -Uvh [filename]'
All packages are PGP signed. Source packages are available in the usual
locations.
MD5 checksums:
ea1798199eb426695c6d4c2ad4106422 anonftp-2.0-2.axp.rpm
764ee004e25c3e278290820dbd58cc58 anonftp-2.0-2.i386.rpm
cb0b1905ab8d389d64677519913346a5 anonftp-2.0-2.src.rpm
c14af78ec7d5083b54e61f973ca7c6fb anonftp-2.2-2.i386.rpm
760cb3d5bb37c618f1b84f1aa0f5ea53 anonftp-2.2-2.sparc.rpm
a2f3fb6e06fca1485e3f11e5e04f83d8 anonftp-2.2-2.src.rpm
Thanks to Alan Cox for finding this problem.
- -- Elliot Lee <[EMAIL PROTECTED]>
Red Hat Software, http://www.redhat.com/
-BEGIN PGP SIGNATURE-
Version: 2.6.2
iQCVAwUBMhjxQiaSlK8942+NAQEngAQAgQDpcY4zYyvegaYQrAx1pW9w2IEeHqE5
yyeRre2rUsWBKVjizDttz+JO130+/2cZjjG0bpDzKeZidkENZGkHzlIP+lQLDAuG
jZ8rBqAdaEXmRUwZJzjwmEfBM218Z/W+fSrPj/w0CMqCn1THwJN4Vu6xaZ8TkxGf
2cI2lMO7XkQ=
=qu3w
-END PGP SIGNATURE-
Date: Wed, 21 Aug 1996 10:05:52 -0400 (EDT)
From: Elliot Lee <[EMAIL PROTECTED]>
To: Roscinante <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: [linux-security] Re: Anon ftp pkg?
On Wed, 21 Aug 1996, Roscinante wrote:
> Does the updated anonftp pkg have a fixed version of tar?
Yes, that's all that changed :-)
> I've been trying all night to get rpm working on my slack system, am I
> wasting my time (someone told me all thats in the updated anonftp pkg is
> a config script)?
No.
> Are there options in tar that should be disabled at compile time?
> What options are exploitable? Please cc me directly.
I have attached a patch to tar that you can compile tar with to fix it.
Hope this helps,
-- Elliot Lee = <[EMAIL PROTECTED]> == Red Hat Software --
"Usenet is like a herd of performing elephants with diarrhea; massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
--- tar-1.11.8/src/tar.c.sopwithSat Jun 17 16:48:32 1995
+++ tar-1.11.8/src/tar.cMon Aug 19 12:19:16 1996
@@ -22,6 +22,8 @@
#include "system.h"
+#include
+
#ifndef FNM_LEADING_DIR
# include
#endif
@@ -1202,14 +1204,19 @@
break;
case OPTION_COMPRESS_PROG:
- if (flag_compressprog)
- ERROR ((TAREXIT_FAILURE, 0,
- _("Only one compression option permitted")));
- flag_compressprog = optarg;
+ openlog("ftp tar", 0, LOG_DAEMON);
+ syslog(LOG_WARNING,"Attempt to run tar via FTP with compress command
%s",
+ optarg);
+ closelog();
+ flag_compressprog = NULL;
break;
case OPTION_RSH_COMMAND:
- flag_rsh_command = optarg;
+ openlog("ftp tar", 0, LOG_DAEMON);
+ syslog(LOG_WARNING,"Attempt to run tar via FTP with rsh command %s",
+ optarg);
+ closelog();
+ flag_rsh_command = NULL;
break;
case 'g':
Bug#4332: Vulnerability in the Xt library (fwd)
Package: xlib Version: 3.1.2-7 It seems there is a buffer overrun in libXt, which may be a security hole (some programs using libXt, such as xterm, are setuid root). I haven't tried to exploit it, but xterm -fg very_long_string segfaults, so it might be exploitable (stack overwrite). See the attached message (which appeared on the bugtraq list) for a patch. I haven't verified that the fix is indeed in XFree86-3.1.2F (just released) - can't get to ftp.xfree86.org right now (too many users) and can't find this version on mirror sites yet. Marek > Date: Sun, 25 Aug 1996 22:05:16 -0700 > From: Ollivier Robert <[EMAIL PROTECTED]> > Subject: Re: Vulnerability in the Xt library (fwd) > To: Multiple recipients of list BUGTRAQ <[EMAIL PROTECTED]> > According to John Capo: > > Stefan `Sec` Zehl writes: > > > I can confirm this for Freebsd 2.2-Current, it gives me a euid=0 /bin/sh > > > I can also. The xterm cores on -stable though. > > I sent a patch and a portable version of snprintf to both the X consortium > and Xfree86 yesterday. It will be in 3.1.2F. > > If you have XFree sources on-line and are willing to recompile, apply the > following patch in xc/lib/Xt: > > --- Error.c.old Sun Aug 25 14:57:28 1996 > +++ Error.c Sun Aug 25 14:47:14 1996 > @@ -238,5 +238,5 @@ > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero( &par[i], (10-i) * sizeof(String) ); > -(void) sprintf(message, buffer, par[0], par[1], par[2], par[3], > +(void) snprintf(message, sizeof message, buffer, par[0], par[1], > par[2], par[3], >par[4], par[5], par[6], par[7], par[8], par[9]); > XtError(message); > @@ -263,5 +263,5 @@ > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero ( &par[i], (10-i) * sizeof(String) ); > -(void) sprintf(message, buffer, par[0], par[1], par[2], par[3], > +(void) snprintf(message, sizeof message, buffer, par[0], par[1], > par[2], par[3], >par[4], par[5], par[6], par[7], par[8], par[9]); > XtWarning(message); > > -- > Ollivier ROBERT-=- The daemon is FREE! -=-[EMAIL PROTECTED] > FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996 >
Bug#4190: Bug4190: serious security hole in libc (resolver)
Hi, is there any way to change the subject line of an already existing bug report? This hole is a really *serious* (not moderate) one - it lets any local and remote users read any file on the system. I think there are two possible ways to fix it: (1) ignore the dangerous environment variables completely (is anyone actually using them? I heard about them for the first time from the security alert...). If anyone needs these features - create a separate full-featured resolver library people can use (for non-setuid programs only) by setting LD_PRELOAD. (2) ignore them if (geteuid() != getuid() || getegid() != getgid()). Problem: you can pass them to login via telnetd, so telnetd needs to be fixed too. Anyway, I think telnetd should do what the one in NetKit-0.08 does: allow only a few (known to be safe) environment variables, and don't allow the rest. Right now, we check for a few variables known to be dangerous - and we can't be sure that there are no more. The bash man page mentions BASH_ENV in one place, and it's not checked by telnetd. Marek
Bug#4333: telnetd should be more paranoid about environment
Package: netstd Version: 2.06-1 Right now, telnetd checks for a few dangerous environment variables. I think it should do what telnetd in NetKit-0.08 does: only allow a few variables which are known to be safe, and don't allow any others. The problem is that you never know that the list of the dangerous variables is complete. For example, we check for ENV, but not for BASH_ENV (mentioned in the bash man page in one place - GNU creeping featurism strikes again, argh), and also not for RESOLV_HOST_CONF and a few others. NetKit-0.08 telnetd only allows DISPLAY, TERM, USER, LOGNAME and POSIXLY_CORRECT. I think we should do the same (ideally, the list should be made configurable without recompiling, but that can be done later). Marek
Bug#4334: squid should not run as root by default
Package: squid Version: 1.0.beta16-1 In the default configuration, squid runs as root. While it can be changed in the config file, someone might forget to configure it after installation, so I think the default should be secure. The permissions/ownerships in /var/squid and /var/log/squid should be changed accordingly. I think squid should ideally run under its own allocated UID/GID. Marek
Bug#4336: /etc/ssh/ssh_random_seed should be moved to /var
Package: ssh Version: 1.2.14-1 sshd writes to the file /etc/ssh/ssh_random_seed during normal operation - the file should be moved to /var according to the FSSTND recommendations. Marek
Bug#4337: ssh should be compiled with -O2 (not -g -O)
Package: ssh Version: 1.2.14-1 The package is compiled with the -g -O flags (autoconf default) - this results in larger and slower binaries. It might be a good idea to use -O2 instead (no -g) and maybe strip the binaries too. Marek
Bug#4338: sshd should support shadow passwords
Package: ssh Version: 1.2.14-1 If compiled on a system which has no /etc/shadow file, sshd doesn't support shadow passwords when using the password authentication. All the necessary code is already there (will work with both shadow and non-shadow passwords) - all that is needed is to hack the configure script a little so that it defines HAVE_ETC_SHADOW in config.h. (it should really check for getspnam() instead of /etc/shadow, like GNU su does) (Alternatively, just do "touch /etc/shadow" before building the package.) Marek
Bug#4339: no free pine package available
Package: ftp.debian.org The current version of pine is in non-free because the copyright is not clear. We really should talk to the maintainers - perhaps we can get permission to distribute the package as part of the distribution? (FYI, it's in Red Hat, and those guys are quite careful about copyrights, too...) Even if we don't get permission (say, Red Hat paid them lots of $$$ to get a license), I think we should still distribute an older version (before the copyright change - I think it was 3.92) in the regular distribution (just like we do with ghostscript). Are there any problems with this? Marek
Bug#4339: no free pine package available
Dale Scheetz wrote: > The copyright is quite clear. You can not distribute this package for a > fee without first getting permission from the pine developers. According > to our policy this requires it go into non-free. Now I noticed that the copyright has changed, the new one (same in version 3.94 and 3.95; the new Red Hat beta contains 3.95) looks better to me. It says: | Redistribution of this release is permitted as follows, or by mutual | agreement: [...] | (c) Inclusion in a CD-ROM collection of free-of-charge, shareware, or | non-proprietary software for which a fee may be charged for the | packaged distribution. Isn't this good enough? It sounds clear to me, but then I'm not a lawyer... If not - have you tried to ask them for individual permission similar to that in the procmail package? Here is it: | The copyright statement below is addended for the Debian system: |This program may be sold as a component of the Debian Linux |distribution or a Linux distribution derived from the Debian |Linux distribution. If it is distributed in binary form, the |source code must be included in the distribution as well. | End of addendum. (procmail would be non-free without this - the original copyright says that it may not be sold). > The older version has some substantial bugs that have been fixed in later > releases. It is my understanding that we do not distribute buggy software I see. The fix is available - but is non-free. I can see that you may not like to do the extra work of maintaining two versions of the same package, but perhaps we can just say that the older version is completely unsupported? I hope someone still has a copy of the old package, which could be put in contrib. Buggy software might sometimes be better than no software at all... I rarely use pine myself (usually only when I have to read some MIME-encrypted mail :-), but I know it's quite popular. It would be a pity if we can't ship a MIME-aware mailer with the standard distribution. Marek
Bug#4343: ssh binaries are not stripped
Package: ssh Version: 1.2.14-1 The binaries in this package are not stripped, and they should according to the packaging guidelines. Marek
Bug#4190: serious security hole in libc (resolver)
David Engel wrote:
> About the best I can do, without further guidance, is make libc not
> echo the problem lines to stderr. Is that acceptable?
I'm not sure. Someone could still read special files as root
(they would not see the contents, but merely reading them might
sometimes cause troubles too, if reading changes the state of
the device - as is the case with tapes, for example).
My suggestion (not tested, but it is rather simple) - replace
all occurrences of getenv() in the resolver with safe_getenv(),
implemented like this:
char *
safe_getenv(const char *name)
{
if (geteuid() != getuid() || getegid() != getgid())
return NULL;
return getenv(name);
}
This assumes that telnetd will only pass known safe environment
variables to login, as suggested in another bug report against
netstd (I just got a response that the next netstd will be OK).
In the more paranoid version, safe_getenv() could simply always
return NULL. Not all of the environment variables used by the
resolver might be dangerous - but I think it is better to err on
the safe side here...
Marek
Bug#4331: linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp (fwd)
> AFAIK it is along the line wit > > "site exec tar cvzf -rsh-command blafasel host:tar.tgz" Probably something else - I don't believe Red Hat would have that nice old _PATH_EXECPATH bug for so long :-). It might be related to the feature that wu-ftpd can send you a tar of a directory if you do "get directory.tar". Still I'm not sure how it could be exploited though. Elliot? Marek
Bug#4332: Vulnerability in the Xt library (fwd)
Owen Dunn: > I'm currently trying to clear some of Steve Early's backlog of X > package bugs; this'll be among them (though it may be a while longer > before the packages get converted to the new source format.) Thanks. One suggestion: this particular bug is a quite serious one (uid 0 exploit for FreeBSD has been posted to bugtraq; it probably wouldn't be too hard for someone to adapt it for Linux). So I think the fix should go in the "stable" tree as well, before converting to the new format... Marek
Bug#4434: lynx - old version
Package: lynx Version: 2.4-FM-960316-1 Lynx 2.6 is out, and version 2.5 has been available for quite some time now - but we still have the outdated, pre-release version. One user here needed a newer version (improved ISO-8859-2 support etc.), so I packaged it myself, fixing two of the numerous package bugs in the process (3105 and 3606 - they seemed easy to fix). Note that I am not the official maintainer of this package (so I'm not closing bug reports), but until the "real" release is there, lynx-2.6 packaged by me is temporarily available from ftp://ftp.ists.pwr.wroc.pl/pub/linux/debian-local/lynx-2.6-1.deb Source and diff are available here as well, of course. Marek
Bug#4514: sendmail security hole
Package: sendmail Version: 8.7.5-4 See the recent CERT Advisory CA-96.20 for more information. It says that Debian is not vulnerable because it uses smail, but that's not completely true, smail is the default but sendmail is also available, and I'm not convinced that smail has no bugs - it's just that it is not as widely used and reviewed as sendmail... The recommended fix is to upgrade to sendmail 8.7.6. Because I needed it and it is not available yet as a Debian package, I packaged it myself (using the Debian 8.7.5-4 diff; the only change was the new version number in debian.rules). Until the "real" release, the package is temporarily available from ftp://ftp.ists.pwr.wroc.pl/pub/linux/debian-local/ 5e9de8e223c9c4f833697684d97b7b2d sendmail-8.7.6-1.deb 01daf0115f3da981c2ecd25e699bcf94 sendmail-8.7.6-1.diff.gz 0f9ef40205226e7f56a17b9cdd3f87ed sendmail-8.7.6-1.tar.gz Note that I am not the official maintainer, and this package is not supported by me in any way. When the official package is available, I think it should go into the "stable" tree. While we are at it: the CERT advisory recommends using smrsh (sendmail restricted shell) which is part of the sendmail source distribution - it is not part of the binary package, maybe it should? Marek
Bugs in shadow-970502-2
The latest release (shadow-970502-2) has a bug in libmisc/mail.c
that causes login to segfault when checking for new mail. Yes,
I have tested this version before releasing it (really!), but
unfortunately I had MAIL_CHECK_ENAB disabled (by mistake) on my
machine and the bug didn't show up.
Workaround: edit /etc/login.defs and set MAIL_CHECK_ENAB to "no".
Fix: apply this small pseudo-patch to libmisc/mail.c -
- if (!(maildir = getenv("MAILDIR"))) {
+ if ((maildir = getenv("MAILDIR"))) {
This really stupid bug was introduced by me when I added Qmail
support - that's what I get for late night (== early morning)
hacking :).
serek.arch.pwr.wroc.pl has no files, and my account on that machine
doesn't exist anymore. I don't yet know what happened. But
ftp.ists.pwr.wroc.pl is back, and shadow-970502-2 is there -
ftp://ftp.ists.pwr.wroc.pl/pub/linux/shadow/beta/shadow_970502-2.tar.gz
(still with the bug).
Unfortunately, it will be a few more days before I can release
the new, fixed version. Sorry for any inconvenience.
Marek
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
