From owner-freebsd-bugs Sun Jul 7 04:30:32 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05629 for bugs-outgoing; Sun, 7 Jul 1996 04:30:32 -0700 (PDT) Received: (from pst@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05614 for freebsd-bugs; Sun, 7 Jul 1996 04:30:29 -0700 (PDT) Date: Sun, 7 Jul 1996 04:30:29 -0700 (PDT) From: Paul Traina Message-Id: <199607071130.EAA05614@freefall.freebsd.org> To: freebsd-bugs Subject: active bugs Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions fo FreeBSD including experimental development code and obsolete releases. Bugs can be in one of several states: open A problem report has been submitted, no sanity checking performed analyzed The report has been examined by a team member and evaluated feedback The problem has been solved, and the originator has been given a patch or a fix has been committed. The PR remains in this state pending a response from the originator. suspended Work on the problem has been postponsed. This happens if a timely solution is not possible or is not cost-effective at the present time. The PR continues to exist, though a solution is not being actively sought. If the problem cannot be solved at all, it will be closed, rather than suspended. closed A problem report is closed when any changes have been integrated, documented, and tested. Critical problems S Submitted Tracker Engr. Description ------------------------------------------------------------------------------- a [1995/01/11] i386/105 bde Distributed libm (msun) has non-standard f [1995/05/28] kern/452 davidg vnode swapping panics f [1995/11/11] bin/817 fenner Wrong route to remote network f [1995/11/27] kern/840 peter Kernel page directory invalid o [1995/12/03] kern/863 davidg panic on kernel page fault, NULL curproc o [1995/12/08] kern/876 mpp NFS allows bogus accesses to cached data o [1996/01/09] kern/940 panic: free vnode isn't o [1996/01/13] ports/944 pst Security fixes for Fvwm 1.24r a [1996/01/22] kern/965 bde 2.0.5: system crashes daily because of "m o [1996/01/29] kern/978 se Three deadlocks in row o [1996/02/08] kern/1008 Daily crash while writing network backups o [1996/02/23] bin/1040 wollman with certain flags, route can reboot your a [1996/03/04] kern/1059 hsu null fs panics system o [1996/04/06] kern/1121 dyson System crashes on boot up just after the o [1996/04/29] kern/1163 2.2-960323-SNAP: fatal trap 12 o [1996/05/07] kern/1177 dyson Machine hangs with message "vm_fork: no p o [1996/05/19] kern/1217 separating to hardrives to two IDE channe o [1996/05/26] kern/1257 dyson System got blown away by "vm_pageout_scan o [1996/06/01] kern/1286 cluster_read() calls strategy routine wit f [1996/06/05] kern/1296 gibbs BUS DEVICE RESET and machine crash with A o [1996/06/08] kern/1302 3COM 3c590 can't receive packets o [1996/06/11] kern/1311 Panic: vm_page_free while installing new o [1996/06/12] ports/1318 Problem making port: squid 23 problems total. Serious problems S Submitted Tracker Engr. Description ------------------------------------------------------------------------------- o [1994/11/30] kern/34 davidg nullfs and union mounts can result in wil o [1995/01/10] bin/104 pax -rwl may corrupt filesystem o [1995/01/24] gnu/183 bde can't resolve "operator <<" overload a [1995/03/20] kern/260 davidg msync and munmap don't bother to update m a [1995/03/20] docs/264 paul There are no manual pages for the forms l a [1995/03/22] kern/267 davidg NFS code gives error messages, systems ja o [1995/04/01] kern/291 se PCI devices still probe/attach after bein o [1995/04/20] kern/353 se xcdplayer crashes machine (with NCR810 SC o [1995/05/08] bin/389 Simultaneous creation/deletion of dirs co a [1995/05/09] bin/392 Simultaneous cp and ls of files on dos f/ o [1995/05/16] kern/425 wollman arp entries not getting removed when inte f [1995/05/25] kern/443 65 sendmails crashes system o [1995/05/26] kern/446 phk unable to diskless-boot a PC when the ser a [1995/06/17] kern/527 dufault dump causes assertion in ncr.c o [1995/06/17] kern/528 bde slow 386 reports excessive interrupt-leve o [1995/07/02] kern/579 bde sio: RS_IBUFSIZE at 256 bytes serial line o [1995/08/01] bin/648 bde printf format conversion incorrect (dupli o [1995/08/15] i386/692 bde My modem is not found if my external cach o [1995/08/21] kern/703 amurai ppp not always deleting route properly wh o [1995/08/22] bin/706 increased root DNS traffic and long laten o [1995/09/19] bin/728 joerg /bin/sh messes up quoting when going thro f [1995/09/20] kern/730 gibbs 3Com 3C5x9 probe problem o [1995/09/21] docs/731 socketpair(2) and man page inconsistent a o [1995/09/26] bin/739 Some problems when an output filter reads o [1995/09/27] kern/745 se occasional filesystem inconsistencies, an o [1995/09/27] bin/747 date(1) gives weird time zones and interp o [1995/09/27] kern/750 cd9660 confused by not-ready or I/O error o [1995/10/05] misc/767 Configure-time does time-warp on non-UTC a [1995/10/07] bin/771 wollman telnet character mode not set and broken o [1995/10/09] kern/774 dump fails with "slave couldn't reopen di o [1995/10/11] bin/777 patch doesn't realize stdin is closed and o [1995/10/12] bin/778 tar complains "EOF not on block boundary" a [1995/10/15] kern/782 davidg chmod does a null pointer dereference o [1995/10/18] bin/786 wpaul Problem with NIS and large group maps a [1995/10/26] kern/794 swap partition at offset 0 still broken o [1995/10/29] kern/798 PPP panics, touches 0xdeadc0de pointers o [1995/11/12] kern/820 gibbs scsi tape problems o [1995/11/16] bin/826 tcpmux listener in inetd does not work o [1995/11/27] kern/845 joerg Automatic reboot says you can abort but b o [1995/11/28] bin/850 dump treats write-protect as an EOT & spo o [1995/12/01] bin/859 joerg /bin/sh -c does not ignore SIGINT o [1995/12/02] kern/860 msmith visual mode in kernel -c is too restricti a [1995/12/04] i386/867 nate Notebook with APM and 3C589C in PCMCIA fr f [1995/12/07] bin/873 fenner Invalid route to remote network o [1995/12/20] i386/906 davidg /sys/i386/boot/netboot/nb8390.com cannot o [1995/12/29] kern/920 bde sio output looses chars in fifo on close( o [1996/01/01] bin/926 Mounting nfs disks before starting mountd o [1996/01/02] kern/927 VGA mode not restored o [1996/01/06] kern/932 de0 occasionally enables 100baseTX when p o [1996/01/12] misc/942 X11 mono server dumps core on supported v o [1996/01/16] kern/949 panic, undebugable dump? o [1996/01/17] kern/951 -current kernel crashes with devfs error o [1996/01/19] kern/956 Kernel page fault, null callp o [1996/01/25] kern/971 Default limits for number of processes pe f [1996/01/27] kern/974 ktrace causes panic: freeing busy page o [1996/01/28] kern/976 se NCR SCSI driver gives assertion errors an o [1996/02/01] bin/986 problems make-ing with cd in the rule o [1996/02/03] kern/991 joerg pcvt keyboard doesn't accept input at cra o [1996/02/06] kern/998 bde badness in file system silently crashes m o [1996/02/10] kern/1016 dyson panic: vm_page_free: freeing free page, s o [1996/02/10] kern/1017 dyson ssh stopped working between 15th Jan and o [1996/02/12] kern/1018 dyson panic: unwire: page not in pmap o [1996/02/12] bin/1019 joerg getty cannot detect ppp logins o [1996/02/12] kern/1020 Boca 16-port board still hangs o [1996/02/12] docs/1023 mpp using touch to create swap file for NFS d o [1996/02/17] bin/1030 joerg /bin/sh does not pass environment variabl o [1996/02/27] kern/1045 Lockup: b_to_q to a clist with no reserve o [1996/02/28] i386/1048 ep driver fails to detect card when told a [1996/02/28] kern/1049 fenner /kernel: arpresolve: can't allocate llinf o [1996/02/28] bin/1050 Process (zip) hangs (unkillable) after fl o [1996/02/29] bin/1052 joerg /bin/sh problem with new GCC (snapshot fo o [1996/03/05] kern/1064 Recursive panic? o [1996/03/06] kern/1065 wt could crash reading short blocks o [1996/03/06] kern/1066 Arnet driver: panic when ifconfig PPP -> a [1996/03/06] kern/1067 mpp panic: ufs_lock: recursive lock not expec o [1996/03/09] ports/1072 asami tex port (ftplib.pl) does not support pas o [1996/03/09] bin/1073 telnet -8 does not work with SunOS or Sol o [1996/03/11] conf/1076 'make install' fails for /usr/src/share/e o [1996/03/16] kern/1081 Fatal double fault o [1996/03/17] kern/1087 Device close entry is not called when unm o [1996/03/21] bin/1095 make's continuation line handling buggy w f [1996/03/21] i386/1097 gibbs system hang during tape rewind/aic7870 co o [1996/03/23] kern/1098 File system corruption (2 cases) o [1996/03/26] kern/1102 smpatel Differentiation of FreeBSD & Linux ELF bi o [1996/03/30] bin/1111 mail.local will happily deliver mail to a o [1996/04/05] kern/1118 panic: setrunqueue encountered when wine o [1996/04/07] kern/1122 Kernel (current) does not see all memory o [1996/04/09] bin/1127 joerg sh(1) parameter expansion for substring p o [1996/04/11] kern/1134 se PPB support is broken for multiple/unknow o [1996/04/11] kern/1135 starting an extra mountd and then killing f [1996/04/14] kern/1140 fenner arpresolve does a null pointer dereferenc o [1996/04/24] kern/1157 SCSI Disk Timeouts (ahc0) o [1996/04/28] kern/1160 Panic: bad dir o [1996/04/28] kern/1161 -current panic on boot if DIAGNOSTIC opti o [1996/04/29] kern/1164 machine locks up o [1996/04/30] kern/1166 pmap panic (dump available) o [1996/05/02] kern/1171 panic: setrunnable after touching long id o [1996/05/08] kern/1180 freeing held page, count=%d o [1996/05/10] misc/1187 pppd dies with a segv o [1996/05/11] kern/1190 panic: page fault (wild pointer?) o [1996/05/14] kern/1204 umount -f after SCSI reset -> reboot o [1996/05/16] kern/1208 Rebooting nfs server results "Permission o [1996/05/17] gnu/1210 gcc (v2.6.3) -O and -O2 compile-time bus o [1996/05/18] bin/1212 ppp eventually runs out of file descripto o [1996/05/18] kern/1213 kernel page fault o [1996/05/21] kern/1227 dyson vm_page_activate: already active (new vm o [1996/05/21] kern/1228 probe doesn't find P-n-P modem o [1996/05/21] bin/1231 make(1) execution of ``.BEGIN'' does not o [1996/05/24] misc/1247 Conflicting header files o [1996/05/24] bin/1248 joerg /bin/sh has trouble with arguments past 9 o [1996/05/26] i386/1251 aha0 and bt0(eisa) conflicts again. o [1996/05/26] kern/1252 Heavy activity on a CD causes panic o [1996/05/26] kern/1256 ZNYX 314 mysterously looses packets o [1996/05/27] kern/1258 dyson new vm code: freeing held page o [1996/05/27] kern/1269 dyson vm_pageout_scan: page not inactive? (loop o [1996/05/28] conf/1270 /etc/ttys does not list all valid ptys (b o [1996/05/28] kern/1271 phk Kernel panic using PLIP in 27/05 current o [1996/05/28] kern/1274 Kernel panics with filesystem error o [1996/05/29] kern/1278 SUN Solaris clients gets host not respond o [1996/05/31] kern/1284 dyson panic: vm_page_free: freeing busy page o [1996/05/31] conf/1285 route_multicast and route_loopback lines o [1996/06/02] bin/1287 joerg /bin/sh does alias expansion in case patt o [1996/06/02] i386/1288 bde wdgetctlr (wd.c) return incorrect number o [1996/06/03] bin/1289 errno breaks in thread-safe c++ compiles o [1996/06/05] kern/1293 Fatal trap 12: page fault while in kernel o [1996/06/06] misc/1299 National charecter problem in XFree86 o [1996/06/07] kern/1301 davidg DEC FDDI/PCI Adapter: halt code = 6 (DMA o [1996/06/09] bin/1305 dc miscomputes remainder o [1996/06/10] kern/1307 vm_page_free: freeing busy page o [1996/06/10] kern/1308 vm_page_free: wire count > 1 in 960501-SN o [1996/06/14] bin/1322 savecore does not take minfree into accou o [1996/06/14] kern/1323 nate 960612's psm driver does not see the mous o [1996/06/15] kern/1326 defvs panic: cleaned vnode isn't o [1996/06/16] kern/1327 joerg keyboard probe in -current fails, X reboo o [1996/06/18] kern/1333 free vnode isn't: another -stable coredum o [1996/06/19] kern/1336 Permission for .. in NFS mounts is somewh o [1996/06/21] misc/1342 jkh chgrp(1) required by MAKEDEV but not on f o [1996/06/22] kern/1345 kernel page fault, NULL pointer dereferen o [1996/06/25] bin/1350 sed continuation lines in text don't work o [1996/06/25] bin/1351 security problem with mv(1) o [1996/06/26] conf/1352 jkh Missing files from /usr/share/info o [1996/07/06] kern/1371 kernel doesn't flush all its buffers when 142 problems total. Non-critical problems S Submitted Tracker Engr. Description ------------------------------------------------------------------------------- a [1994/12/01] kern/35 bde mount -t union -o -b : lower layer not se o [1995/01/14] bin/115 bde systat iostat display doesn't scale high o [1995/01/14] bin/129 davidg fsck cannot take a mount point as an argu o [1995/01/15] bin/146 version of compress is kinda old and slow o [1995/01/21] bin/173 jkh rc trys to mount modload fs before ld is o [1995/01/21] bin/174 Poor error message from stty o [1995/01/22] kern/176 peter EIDRM not defined in errno.h o [1995/01/24] bin/184 pst send-pr says "Aborting ..." and happily r o [1995/01/30] bin/198 asami 1.1.5.1 pine binary loops; top shows fanc o [1995/03/28] kern/281 Messages printed when checking CD ROM dev o [1995/03/28] kern/282 gibbs buslogic adapter information WAY too verb a [1995/04/09] bin/326 Weekly cron generates some usage and erro o [1995/04/20] misc/355 policy on /usr/local permission in base r o [1995/05/12] bin/398 scrappy VI doesnt do the correct thing o [1995/05/13] bin/401 wollman Add REMOTE_* variables o [1995/05/15] misc/423 Sound devices are too insecure o [1995/05/23] i386/440 sos want vidcontrol option to apply settings a [1995/05/27] gnu/450 scrappy tar --exclude -c doesn't work o [1995/06/15] bin/517 wpaul Bad group change with 'install' o [1995/07/05] bin/591 phk SPAP request REJexted in stead of NAKed o [1995/08/05] gnu/655 jdp ld -r of shared objects worked in 1.1.5, o [1995/08/07] bin/658 wollman ifconfig alias has to be separately given o [1995/08/07] bin/661 Hercules is not capable of having a ISO-L o [1995/08/11] ports/673 joerg /bin/sh + inn1.4 innwatch going belly up o [1995/08/11] bin/675 make does unnecessary rebuilds o [1995/08/12] kern/677 dyson X gets a bus error when calling mmap() o [1995/08/13] bin/680 joerg 2.0.5's tip using termios doesn't act the o [1995/08/18] kern/700 fenner The comments in /sys/net/if.h are confusi o [1995/08/29] bin/715 ache ls gives weird tabular form o [1995/09/23] docs/735 wollman missing description for mount options in o [1995/09/26] kern/742 dyson syslog errors accessing Mac hard disks [p o [1995/09/27] bin/743 scrappy vi cannot edit a file where the name star o [1995/09/28] kern/752 wollman setting multiple addresses for a single i o [1995/09/28] kern/753 joerg my archive scsi tape drive does not work o [1995/09/28] docs/754 nate there is no man page for the psm(4) mouse o [1995/10/03] kern/765 phk umount -f can`t umount a NFS filesystem i o [1995/10/14] kern/781 bde OPEN_MAX in kernel config and FD_SETSIZE o [1995/10/25] kern/792 dyson cd9660 very slow. o [1995/10/29] docs/801 mpp rlogind k, v, and x options are not docum o [1995/10/31] bin/803 bsd m4 chokes and dies while FSF m4 works o [1995/11/11] bin/815 mountd reports unknown hosts with non-inf o [1995/11/13] kern/821 Config doesn't properly trap signals o [1995/11/20] kern/831 one minor complaint about the kernel visu o [1995/11/22] kern/835 davidg ed panics with SMC ultra with iomem, if n o [1995/11/25] bin/839 by default, use of "at" is overly restric o [1995/11/27] bin/841 stale nfs mounts cannot be umounted o [1995/11/28] misc/848 jkh Inst gripes about geometry but won't acce o [1995/11/30] bin/854 swapinfo shows incorrect information for o [1995/11/30] ports/857 asami Need ANSI_C define to not declare some fu o [1995/12/03] kern/861 sb16 support in 2.1 is erratic and has co o [1995/12/06] ports/871 asami port.subdir.mk DEBUG_FLAGS is not used fo o [1995/12/17] kern/900 dyson ext2fs triggers divide by zero trap in vn o [1995/12/25] bin/914 hayes dialer for tip fails 1st attempt to a [1995/12/29] misc/922 From line handling incorrect in mail.loca o [1995/12/31] kern/924 EISA devices have disappeared from vmstat o [1996/01/06] misc/934 amurai ppp dies with Bus Error when processing l o [1996/01/15] kern/946 divide-by-zero in kernel on bad disk info o [1996/01/19] bin/958 ttys file does not include all ptys o [1996/01/21] bin/961 'more $file', incorrect CRLF compacting. o [1996/01/23] ports/968 asami Netscape & cern_httpd ports out of date/d o [1996/01/28] kern/975 bde getrusage returns negative deltas a [1996/01/30] bin/981 fenner clnt_broadcast() is not aware of aliases o [1996/02/03] bin/993 g++ complains about /usr/include/machine/ o [1996/02/07] bin/999 peter /usr/share/mk/sys.mk missing common $(RM) o [1996/02/07] kern/1001 bde M_NAMEI malloc leak in the kernel o [1996/02/09] kern/1012 vnode_pager_putpages: attempt to write me o [1996/02/12] bin/1021 phk pppd doesn't handle PAP-only authenticati o [1996/02/14] kern/1026 deadlocks if parent vfork and child has c o [1996/02/14] bin/1028 shutdown -r does not seem to always compl o [1996/02/15] bin/1029 cd behaves erraticly if cwd is a mount-po o [1996/02/19] bin/1035 ls to terminal always uses ? for non-prin o [1996/02/19] docs/1036 mpp List of dead xrefs in man pages o [1996/02/19] bin/1037 2.x telnetd handles CTRL-M differently th o [1996/02/25] i386/1042 bde Warning from sio driver reports wrong dev o [1996/02/26] misc/1043 dyson vm_bounce_alloc error on 2.1 install with o [1996/02/27] gnu/1047 send-pr: Aborting... o [1996/02/29] kern/1051 zip fails on dos partition o [1996/03/02] bin/1056 pppd fails if -detach o [1996/03/08] bin/1068 man ignores -P option when combined with o [1996/03/08] ports/1069 TkMan acts erroneusly on apropos o [1996/03/09] bin/1070 /usr/bin/fstat doesn't display open, acti o [1996/03/09] bin/1074 tty rows & columns settings sometimes res o [1996/03/18] docs/1089 stat manpage unclear about st_mtime & fri o [1996/03/20] kern/1090 iostat displays incorrect sps count o [1996/03/20] bin/1093 wollman route's diagnostic is weird o [1996/03/28] bin/1105 Bug in find command o [1996/03/28] ports/1109 asami mods to vim-3.0 port o [1996/04/06] kern/1119 dyson Mounted EXT2FS partition is not cleanly u o [1996/04/12] bin/1136 joerg broken printf in sh(1) o [1996/04/14] bin/1139 uname.1 and uname.c disagree about displa o [1996/04/14] docs/1141 mpp pcvt(4) references non-existent man page. o [1996/04/15] kern/1144 sig{add, del}set and sigismember fns don' o [1996/04/15] bin/1145 tftpd should support -s o [1996/04/19] docs/1151 mpp intro(3) references libc(3) and plot(3), o [1996/04/22] bin/1154 Configure tunN device for ip-over-ip tunn o [1996/04/23] ports/1155 systat or top display disagreeing informa o [1996/04/25] bin/1158 atq uses GMT time instead of TZ time a [1996/05/01] ports/1168 asami New version of pine. 3.93 fixes bugs in o [1996/05/02] docs/1169 mpp bogus reference to keysu(1) in key(1) and o [1996/05/02] docs/1170 mpp include files missing from get{peer,sock} o [1996/05/09] bin/1181 fsck displays wrong char in "option?" dia o [1996/05/09] bin/1182 timed records improper entry in wtmp o [1996/05/09] bin/1184 scrappy ls + xterm + nvi + columns != 80 + ^Z = m o [1996/05/13] ports/1200 asami pop3 requests may crash client o [1996/05/13] kern/1201 FreeBSD SCSI changer driver leaves a bit o [1996/05/15] bin/1206 /bin/sh + emacs + ^G = ruined terminal o [1996/05/16] gnu/1209 send-pr should refuse PR's without subjec o [1996/05/19] kern/1216 Support for i586 clock clibration is not o [1996/05/20] bin/1221 new gcc-2.7.2 gives a LOT of warnings, an o [1996/05/20] ports/1222 Header files conflict o [1996/05/21] bin/1229 redundant redeclaration of `lseek' o [1996/05/21] bin/1230 make ``.for'' loops iterate backwards o [1996/05/22] kern/1236 joerg some #def's in pcvt_conf.h not braketed b o [1996/05/25] docs/1249 incorrect manpages o [1996/05/27] conf/1264 panic with two new Quantum FireBall 1280 o [1996/05/27] kern/1265 joerg warnings in pcv o [1996/05/28] docs/1272 document the -o option for f2c o [1996/05/28] bin/1273 remote hostname gets corrupted in rshd o [1996/05/31] kern/1283 joerg cleaning out some compiler fuzz from pcvt o [1996/06/11] bin/1312 automounter hangs on boot o [1996/06/12] bin/1316 10 tunnel device limit o [1996/06/12] conf/1319 muldi3 is not included into kernel's Make o [1996/06/13] bin/1320 dump limits blocksize to 32K o [1996/06/18] i386/1331 changes and bug in ft driver o [1996/06/18] bin/1332 changes to amd and possible nfs lkm bug? o [1996/06/19] misc/1335 /etc/security generates an error with fil o [1996/06/20] bin/1337 Yacc skeleton parser generates warning wi o [1996/06/26] ports/1357 fvwm95-2c no longer exists -- fvwm95-2f i o [1996/07/03] bin/1363 ellipses are three dots, not two. o [1996/07/04] i386/1367 reprobe a device that does not exist = pa o [1996/07/04] misc/1369 Need SC_MORE_LUS for Emulex MD23 also o [1996/07/06] misc/1372 compile time error with cc -ansi and RPC o [1996/07/06] misc/1373 RPC include lacks prototypes o [1996/07/06] docs/1374 the default listed in the newfs -i man pa 134 problems total. From owner-freebsd-bugs Sun Jul 7 05:10:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA19148 for bugs-outgoing; Sun, 7 Jul 1996 05:10:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA19133; Sun, 7 Jul 1996 05:10:02 -0700 (PDT) Date: Sun, 7 Jul 1996 05:10:02 -0700 (PDT) Message-Id: <199607071210.FAA19133@freefall.freebsd.org> To: freebsd-bugs Cc: From: Bruce Evans Subject: Re: docs/1374: incorrect default for the -i option in the newfs(8) man page Reply-To: Bruce Evans Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR docs/1374; it has been noted by GNATS. From: Bruce Evans To: FreeBSD-gnats-submit@freebsd.org, marcs@worldgate.com Cc: Subject: Re: docs/1374: incorrect default for the -i option in the newfs(8) man page Date: Sun, 7 Jul 1996 22:02:14 +1000 >>Fix: > >Change 2048 to 4096 in the description for the default of the -i >option in the man page, assuming there are a minimal number of >situations where fsize could end up being something other than 1024. Don't assume. Say that the default is 4 times the fragment size. I changed the default to 2048 bytes in my version of newfs, but I now think that 4 fragments is better - 2048 is usually too small, and doesn't scale properly (for fragments larger than 4096, it would give more inodes than possible files). Bruce From owner-freebsd-bugs Sun Jul 7 14:40:09 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16227 for bugs-outgoing; Sun, 7 Jul 1996 14:40:09 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16191; Sun, 7 Jul 1996 14:40:05 -0700 (PDT) Resent-Date: Sun, 7 Jul 1996 14:40:05 -0700 (PDT) Resent-Message-Id: <199607072140.OAA16191@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, james@jraynard.demon.co.uk Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA15860 for ; Sun, 7 Jul 1996 14:31:12 -0700 (PDT) Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ab17519; 7 Jul 96 22:31 +0100 Received: from jraynard.demon.co.uk ([158.152.42.77]) by relay-3.mail.demon.net id aa22505; 7 Jul 96 22:21 +0100 Received: (from james@localhost) by jraynard.demon.co.uk (8.6.12/8.6.12) id VAA14441; Sun, 7 Jul 1996 21:02:14 GMT Message-Id: <199607072102.VAA14441@jraynard.demon.co.uk> Date: Sun, 7 Jul 1996 21:02:14 GMT From: James Raynard Reply-To: james@jraynard.demon.co.uk To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/1375: Extraneous warning from mv(1) Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1375 >Category: bin >Synopsis: Extraneous warning from mv(1) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jul 7 14:40:02 PDT 1996 >Last-Modified: >Originator: James Raynard >Organization: James Raynard, Edinburgh, Scotland >Release: FreeBSD 2.1-STABLE i386 >Environment: FreeBSD-2.1.0-RELEASE >Description: Observed by Zach Heilig . When moving a file owned by the user, and by a group the user is *not* a member of, across filesystems, an extraneous warning is generated. Such files are typically created when a user writes to a directory with the sticky bit set, eg /tmp. According to mv(1), moving a file across filesystems is equivalent to calling cp -pRP, surrounded by calls to rm(1). According to cp(1), when the -p option is used, no error message should be displayed if the user and group ID of the file cannot be preserved. mv(1) behaves as expected if the file and its destination directory are on the same filesystem, or if a directory is moved across a filesystem instead of a file. >How-To-Repeat: For a user not in wheel, on a system where /tmp and /home are on different devices, $ touch /tmp/foo $ mv /tmp/foo ~ will give a warning about not being able to set owner/group on ~/foo. This does not occur if /tmp and ~ are on the same filesystem, or if foo is a directory. >Fix: Apply the following patch to 2.1.0-RELEASE in /usr/src/bin/mv --- mv.c.orig Sun Jul 7 20:39:38 1996 +++ mv.c Sun Jul 7 20:41:30 1996 @@ -231,8 +231,8 @@ } (void)close(from_fd); - if (fchown(to_fd, sbp->st_uid, sbp->st_gid)) - warn("%s: set owner/group", to); + (void)fchown(to_fd, sbp->st_uid, sbp->st_gid) + if (fchmod(to_fd, sbp->st_mode)) warn("%s: set mode", to); >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Jul 7 22:50:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09170 for bugs-outgoing; Sun, 7 Jul 1996 22:50:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09156; Sun, 7 Jul 1996 22:50:02 -0700 (PDT) Resent-Date: Sun, 7 Jul 1996 22:50:02 -0700 (PDT) Resent-Message-Id: <199607080550.WAA09156@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, risner@stdio.com Received: from generations.stdio.com (generations.stdio.com [204.152.114.70]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA08204 for ; Sun, 7 Jul 1996 22:40:22 -0700 (PDT) Received: (from root@localhost) by generations.stdio.com (8.7.5/8.7.3) id FAA00653; Mon, 8 Jul 1996 05:40:11 GMT Message-Id: <199607080540.FAA00653@generations.stdio.com> Date: Mon, 8 Jul 1996 05:40:11 GMT From: Charlie Root Reply-To: risner@stdio.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: misc/1376: if_tun.c does not init obytes and ibytes Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1376 >Category: misc >Synopsis: if_tun.c does not set if_ibytes and if_obytes to zero. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Jul 7 22:50:01 PDT 1996 >Last-Modified: >Originator: Charlie & >Organization: Open World >Release: FreeBSD 2.1-STABLE 062796 i386 >Environment: PPP tunnel device >Description: the if_tun.c net device does (062796) increment number of bytes and number of packets, but only initilizes number of packets to zero. >How-To-Repeat: Look at line 116-117 of if_tun.c where it sets up the initial variables. >Fix: 117d116 < ifp->if_ibytes = 0; 119d117 < ifp->if_obytes = 0; I think this should be fine. please someone who knows more, review and include. James Risner >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Jul 8 01:30:12 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA16677 for bugs-outgoing; Mon, 8 Jul 1996 01:30:12 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA16658; Mon, 8 Jul 1996 01:30:07 -0700 (PDT) Date: Mon, 8 Jul 1996 01:30:07 -0700 (PDT) Message-Id: <199607080830.BAA16658@freefall.freebsd.org> To: freebsd-bugs Cc: From: Bruce Evans Subject: Re: bin/1375: Extraneous warning from mv(1) Reply-To: Bruce Evans Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/1375; it has been noted by GNATS. From: Bruce Evans To: FreeBSD-gnats-submit@FreeBSD.org, james@jraynard.demon.co.uk Cc: Subject: Re: bin/1375: Extraneous warning from mv(1) Date: Mon, 8 Jul 1996 18:24:01 +1000 >According to mv(1), moving a file across filesystems is equivalent to >calling cp -pRP, surrounded by calls to rm(1). According to cp(1), >when the -p option is used, no error message should be displayed if >the user and group ID of the file cannot be preserved. This is probably a bug in mv.1. mv should and does try harder than cp to preserve attributes. >mv(1) behaves as expected if the file and its destination directory >are on the same filesystem, or if a directory is moved across a >filesystem instead of a file. The latter is a bug in mv. It really does use cp -pRP in this case, but cp -pRP is inadequate. It snaps links, doesn't preserve preservable directory timestamps, and does the wrong thing for `mv dir existing-dir'. There should also be warnings for failures to preserve flags. The fastcopy() case of mv doesn't actually attempt to preserve flags, although the cp -pRP case does (try `touch /tmp/z; chflags nodump /tmp/z; mv /tmp/z anotherfs'). Bruce From owner-freebsd-bugs Mon Jul 8 08:38:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA12489 for bugs-outgoing; Mon, 8 Jul 1996 08:38:04 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA12458; Mon, 8 Jul 1996 08:37:50 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0udINC-0004g0C; Mon, 8 Jul 96 10:37 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id KAA20487; Mon, 8 Jul 1996 10:36:42 -0500 Message-Id: <199607081536.KAA20487@sunc210.tellabs.com> Subject: Re: 2.1-960627-SNAP: YP problem To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 8 Jul 1996 10:36:41 -0500 (CDT) Cc: bugs@freebsd.org, hackers@freebsd.org, mikebo (Mike Borowiec) In-Reply-To: <199607040125.VAA03325@skynet.ctr.columbia.edu> from "Bill Paul" at Jul 3, 96 09:25:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill wrote: > Of all the gin joints in all the world, mikebo@tellabs.com had to walk > into mine and say: > > > > I believe a bug has been introduced into the 2.1-960627-SNAP YP code. > > As it turns out, netgroups have nothing to do with this problem. It is > > a problem with any YP password entries from my Sun server... I've added > > +::::::::: when editing the password file (with vipw), but NONE of the > > users in the NIS password map can login. > I've also tried the string "+:::::0:0:::" as suggested by Mike Murphy, but still no difference. > See if you can do 'id ' and have it recognise the > user in the NIS passwd map. If this works, then it is reading the > passwd map correctly. > Check this out: toybox> id mikebo id: mikebo: No such user toybox> ypmatch mikebo passwd mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh As suggested, I built and installed the following test program: #include #include #include main(argc, argv) int argc; char *argv[]; { struct passwd *pw; char *p, *ep, *salt; pw = getpwnam(argv[1]); salt = pw->pw_passwd; printf("Username is: [%s]\n", pw->pw_name); printf("UID is: [%lu]\n", pw->pw_uid); printf("Password is : [%s]\n", pw->pw_passwd); p = (char*)getpass((const char*)"Password:"); ep = (char*)crypt((const char*)p, (const char*)salt); printf("EPassword is: [%s]\n", ep); exit(0); } > 4) Run the program like this: > > $ pwtest nisuser > > where 'nisuser' is the username of a user that appears in the NIS > passwd maps. > Here's the output: toybox> ./pwtest mikebo Username is: [mikebo] UID is: [1874] Password is : [iXmhD1ZBZJbLI] Password: EPassword is: [iXmhD1ZBZJbLI] Looks good to me, but I still can't login: sunc210> telnet toybox Trying 138.111.12.69... Connected to toybox. Escape character is '^]'. FreeBSD (toybox.hq.tellabs.com) (ttyp1) login: mikebo Password: Login incorrect > (Try it with the +@myuser:::::::: entry too, just for kicks.) > Did that... no difference. > If the output looks exactly correct, then expand the program to > include a call to crypt(3) and compare the results with the encrypted > password show in the pw_passwd field. > Did that... Looks like NIS is working fine, and some programs/libraries are simply ignoring the fact that there are valid YP tokens in the passwd files. The DES package was installed at the same time as the install, and all appeared to complete flawlessly. The login program: toybox> ls -l /usr/bin/login -r-sr-xr-x 1 root bin 20480 Jun 28 03:59 /usr/bin/login toybox> cksum /usr/bin/login 957853657 20480 /usr/bin/login I appreciate all the help. What next? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Mon Jul 8 11:30:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27822 for bugs-outgoing; Mon, 8 Jul 1996 11:30:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27808; Mon, 8 Jul 1996 11:30:02 -0700 (PDT) Date: Mon, 8 Jul 1996 11:30:02 -0700 (PDT) Message-Id: <199607081830.LAA27808@freefall.freebsd.org> To: freebsd-bugs Cc: From: "Gary Palmer" Subject: Re: misc/1376: if_tun.c does not init obytes and ibytes Reply-To: "Gary Palmer" Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR misc/1376; it has been noted by GNATS. From: "Gary Palmer" To: risner@stdio.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: misc/1376: if_tun.c does not init obytes and ibytes Date: Mon, 08 Jul 1996 19:25:56 +0100 Charlie Root wrote in message ID <199607080540.FAA00653@generations.stdio.com>: > >Fix: > 117d116 > < ifp->if_ibytes = 0; > 119d117 > < ifp->if_obytes = 0; > I think this should be fine. No, the patch is reversed :-) The correct way is probably to either bzero/memset the structure array to be all 0's, or to ensure that the array gets dumped into the zero-initialised area of the kernel. No doubt Bruce has comments on the above :-) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-bugs Mon Jul 8 16:12:28 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16815 for bugs-outgoing; Mon, 8 Jul 1996 16:12:28 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA16802 for ; Mon, 8 Jul 1996 16:12:12 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id TAA17851; Mon, 8 Jul 1996 19:10:46 -0400 From: Bill Paul Message-Id: <199607082310.TAA17851@skynet.ctr.columbia.edu> Subject: Re: 2.1-960627-SNAP: YP problem To: mikebo@tellabs.com Date: Mon, 8 Jul 1996 19:10:45 -0400 (EDT) Cc: bugs@freebsd.org In-Reply-To: <199607081536.KAA20487@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 8, 96 10:36:41 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, mikebo@tellabs.com had to walk into mine and say: > Bill wrote: > > Of all the gin joints in all the world, mikebo@tellabs.com had to walk > > into mine and say: > > > > > > I believe a bug has been introduced into the 2.1-960627-SNAP YP code. > > > As it turns out, netgroups have nothing to do with this problem. It is > > > a problem with any YP password entries from my Sun server... I've added > > > +::::::::: when editing the password file (with vipw), but NONE of the > > > users in the NIS password map can login. > > > I've also tried the string "+:::::0:0:::" as suggested by Mike Murphy, > but still no difference. This should not matter. For the moment, you only want +::::::::: anyway. To make sure I wasn't nuts, I installed the same SNAP release on the test machine in my office. We should now have a common reference point. I've configured the machine as an NIS and NFS client on my network (using the automounter to get maps via NIS too) and it all seems to work. Note that I installed the SNAP completely from scratch - I did _not_ do an upgrade. (This may have something to do with it - read on.) > > See if you can do 'id ' and have it recognise the > > user in the NIS passwd map. If this works, then it is reading the > > passwd map correctly. > > > > Check this out: > > toybox> id mikebo > id: mikebo: No such user > toybox> ypmatch mikebo passwd > mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh Okay, check _this_ out: marple# uname -sr FreeBSD 2.1-960627-SNAP marple# ypwhich sirius.ctr.columbia.edu marple# id wpaul uid=1063(wpaul) gid=21(sysman) groups=21(sysman) 0(wheel) 19(src-lscned) 18(src) 125(devnit) marple# ypmatch wpaul passwd.byname wpaul:tI3sbKCXoOHfY:1063:21:Bill Paul:/homes/wpaul:/bin/tcsh marple# ypmatch 1063 passwd.byuid wpaul:tI3sbKCXoOHfY:1063:21:Bill Paul:/homes/wpaul:/bin/tcsh Check that you exist correctly in both the passwd.byname and passwd.byuid maps. Check also that both of these maps has valid data in them. (By valid I mean with the correct number of fields and such.) For reference, my /etc/master.passwd looks like this (I don't mind showing you the encrypted passwords -- they'll be changed shortly :) : marple# cat /etc/master.passwd root:KBO1w243/.2XA:0:0::0:0:Charlie &:/root:/bin/csh toor:*:0:0::0:0:Bourne-again Superuser:/root: daemon:*:1:31::0:0:Owner of many system processes:/root: operator:jNfGj.GU4RB6g:2:20::0:0:System &:/usr/guest/operator:/bin/csh bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent games:*:7:13::0:0:Games pseudo-user:/usr/games: news:*:8:8::0:0:News Subsystem:/:/nonexistent man:*:9:9::0:0:Mister Man Pages:/usr/share/man: uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/nonexistent nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/nonexistent +@marple-users::::::::: +@super-people::::::::: +@SUG-people::32767:32767::::::/usr/local/etc/auth +@Snet-people::32767:32767::::::/usr/local/etc/auth +@acorn-people::32767:32767::::::/usr/local/etc/auth +@ctrnet-people::32767:32767::::::/usr/local/etc/auth +@image-people::32767:32767::::::/usr/local/etc/auth +@tnl-people::32767:32767::::::/usr/local/etc/auth +@sgi-people::32767:32767::::::/usr/local/etc/auth +@deleted1-people::32767:32767::::::/usr/local/etc/disabled +@deleted2-people::32767:32767::::::/usr/local/etc/disabled If I replace all the +@netgroup entries with just +:::::::::, it also works. I'm also bound to a SunOS 4.1.3 NIS server. > As suggested, I built and installed the following test program: > > #include > #include > #include <---- you don't need this, but whatever > > main(argc, argv) > int argc; > char *argv[]; > { > struct passwd *pw; > char *p, *ep, *salt; > > pw = getpwnam(argv[1]); > salt = pw->pw_passwd; > > printf("Username is: [%s]\n", pw->pw_name); > printf("UID is: [%lu]\n", pw->pw_uid); > printf("Password is : [%s]\n", pw->pw_passwd); > p = (char*)getpass((const char*)"Password:"); > ep = (char*)crypt((const char*)p, (const char*)salt); > printf("EPassword is: [%s]\n", ep); > > exit(0); > } > > > 4) Run the program like this: > > > > $ pwtest nisuser > > > > where 'nisuser' is the username of a user that appears in the NIS > > passwd maps. > > > Here's the output: > toybox> ./pwtest mikebo > Username is: [mikebo] > UID is: [1874] > Password is : [iXmhD1ZBZJbLI] > Password: > EPassword is: [iXmhD1ZBZJbLI] > > Looks good to me, but I still can't login: > sunc210> telnet toybox > Trying 138.111.12.69... > Connected to toybox. > Escape character is '^]'. > > FreeBSD (toybox.hq.tellabs.com) (ttyp1) > > login: mikebo > Password: > Login incorrect Okay, things to check: 1) Are you running kerberos? (probably not, but it's worth a shot. :) 2) Did you upgrade to the SNAP by installing it fresh, or did you 'upgrade' by installing over a previous version? 2a) If you 'upgraded,' did you make sure you have only one version of libc.so.whatever in /usr/lib? 3) Are you _SURE_ that you don't have an entry in your /etc/master.passwd file that says +::0:0::::::? Maybe one you missed? 4) Are you _SURE_ they you ran pwd_mkdb after you edited /etc/master.passwd? 5) Did you re-run ldconfig after you installed the DES package? (Rebooting accomplishes the same thing -- if you've rebooted the machine since the DES package went in, the answer is 'yes.') 6) If you do 'ldd /usr/bin/login' does it show it to be linking against the correct version of libc.so.whatever? For reference, this is what it says for me: marple# ldd /usr/bin/login /usr/bin/login: -lutil.2 => /usr/lib/libutil.so.2.1 (0x801d000) -lskey.2 => /usr/lib/libskey.so.2.0 (0x802c000) -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8032000) -lc.2 => /usr/lib/libc.so.2.2 (0x8047000) 6a) Also do an 'ldd test_program_you_built_earlier' and compare the output with 'ldd /usr/bin/login'. 7) Did you check /var/log/messages for suspicious messages resulting from the failed login attempts? 8) If you log in as root, can you do 'su mikebo?' 8a) If so, if you then type 'whoami' does it say 'mikebo?' > Looks like NIS is working fine, and some programs/libraries are simply > ignoring the fact that there are valid YP tokens in the passwd files. Well, all the references are either within libc, or inside a small number of statically linked programs (e.g. those in /bin). I'm beginning to suspect a libc mismatch of some kind. These are the C libraries I have on my system: marple# ls -l /usr/lib/libc.* -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2 (Note that I don't have the profiled libraries installed. This shouldn't make any difference.) My libcrypt setup looks like this (sorry for the long lines): marple# ls -l /usr/lib/*crypt* lrwxr-xr-x 1 bin bin 13 Jul 5 14:07 /usr/lib/libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 bin bin 18 Jul 5 14:07 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 bin bin 15 Jul 5 14:07 /usr/lib/libcrypt_p.a -> libdescrypt_p.a -r--r--r-- 1 bin bin 10690 Jun 28 04:47 /usr/lib/libdescrypt.a -r--r--r-- 1 bin bin 18145 Jun 28 04:47 /usr/lib/libdescrypt.so.2.0 -r--r--r-- 1 bin bin 12362 Jun 28 04:47 /usr/lib/libdescrypt_p.a -r--r--r-- 1 bin bin 4576 Jun 28 04:47 /usr/lib/libscrypt.a -r--r--r-- 1 bin bin 12755 Jun 28 04:47 /usr/lib/libscrypt.so.2.0 > The DES package was installed at the same time as the install, and all > appeared to complete flawlessly. The login program: > toybox> ls -l /usr/bin/login > -r-sr-xr-x 1 root bin 20480 Jun 28 03:59 /usr/bin/login > toybox> cksum /usr/bin/login > 957853657 20480 /usr/bin/login > > I appreciate all the help. What next? This depends on whether you did a complete reinstall or an upgrade. The reason I'm curious is this: I did change the getpwent(3) code in libc rather substantially between the June 27th SNAP and the previous one. Actually, what I did was sync the 2.1-STABLE version with the 2.2-current version, which had survived for several weeks in the -current tree without any trouble (no angry mobs came calling for my head), so I moved it over. The newer version is a bit less messy than the previous one and fixes some bugs. Also, /usr/include/pwd.h and /usr/sbin/pwd_mkdb changed a little since they and getpwent(3) are intimately related. The result is that if you somehow managed to keep an older version of libc.so around (like from the previous SNAP) you might have conflicts since the older getpwent(3) NIS code is not strictly forward compatible (the new version is backward compatible though). Basically, if you use the new pwd_mkdb to create a hash user database with NIS entries, the old getpwent(3) will not be able to grok it properly. This sounds a lot like what's happening here. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." ============================================================================= From owner-freebsd-bugs Mon Jul 8 16:41:34 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA20560 for bugs-outgoing; Mon, 8 Jul 1996 16:41:34 -0700 (PDT) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA20530; Mon, 8 Jul 1996 16:41:30 -0700 (PDT) Date: Mon, 8 Jul 1996 16:41:30 -0700 (PDT) From: Mike Pritchard Message-Id: <199607082341.QAA20530@freefall.freebsd.org> To: mpp, freebsd-bugs, mpp Subject: Re: docs/1374 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: the default listed in the newfs -i man page does not agree with that in the source Responsible-Changed-From-To: freebsd-bugs->mpp Responsible-Changed-By: mpp Responsible-Changed-When: Mon Jul 8 16:40:28 PDT 1996 Responsible-Changed-Why: Doc update - there are also a few other things in this man page that need updating that are on my list. From owner-freebsd-bugs Mon Jul 8 19:55:16 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA28678 for bugs-outgoing; Mon, 8 Jul 1996 19:55:16 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA28673 for ; Mon, 8 Jul 1996 19:55:13 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0udSwf-0004fHC; Mon, 8 Jul 96 21:54 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id VAA21062; Mon, 8 Jul 1996 21:54:01 -0500 Message-Id: <199607090254.VAA21062@sunc210.tellabs.com> Subject: Re: 2.1-960627-SNAP: YP problem To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 8 Jul 1996 21:54:00 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org In-Reply-To: <199607082310.TAA17851@skynet.ctr.columbia.edu> from "Bill Paul" at Jul 8, 96 07:10:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill - You wrote: > > > Of all the gin joints in all the world, mikebo@tellabs.com had to walk > > > into mine and say: > > > > > I believe a bug has been introduced into the 2.1-960627-SNAP YP code. > > > > As it turns out, netgroups have nothing to do with this problem. It is > > > > a problem with any YP password entries from my Sun server... I've added > > > > +::::::::: when editing the password file (with vipw), but NONE of the > > > > users in the NIS password map can login. > > > > Note that I installed the SNAP completely from scratch - I did _not_ > do an upgrade. (This may have something to do with it - read on.) > I did an install from scratch. toybox> uname -sr FreeBSD 2.1-960627-SNAP toybox> ypwhich sunc.lisle.tellabs.com toybox> id mikebo id: mikebo: No such user toybox> id uid=1874 euid=0(root) gid=10(staff) groups=10(staff), 0(wheel), 14(train), 381(netis), 2(kmem), 4(tty), 237(ecfreq), 111(slip), 380(isstaff), 23(tools), 3(sys), 22(tellab5) toybox> ypmatch mikebo passwd.byname mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh toybox> ypmatch 1874 passwd.byuid mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh > Check that you exist correctly in both the passwd.byname and passwd.byuid > maps. Check also that both of these maps has valid data in them. (By valid > I mean with the correct number of fields and such.) > Looks good to me... > For reference, my /etc/master.passwd looks like this (I don't mind > showing you the encrypted passwords -- they'll be changed shortly :) : > > marple# cat /etc/master.passwd > root:KBO1w243/.2XA:0:0::0:0:Charlie &:/root:/bin/csh > toor:*:0:0::0:0:Bourne-again Superuser:/root: > daemon:*:1:31::0:0:Owner of many system processes:/root: > operator:jNfGj.GU4RB6g:2:20::0:0:System &:/usr/guest/operator:/bin/csh > bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent > games:*:7:13::0:0:Games pseudo-user:/usr/games: > news:*:8:8::0:0:News Subsystem:/:/nonexistent > man:*:9:9::0:0:Mister Man Pages:/usr/share/man: > uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico > xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/nonexistent > nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/nonexistent > +@marple-users::::::::: > +@super-people::::::::: > +@SUG-people::32767:32767::::::/usr/local/etc/auth > +@Snet-people::32767:32767::::::/usr/local/etc/auth > +@acorn-people::32767:32767::::::/usr/local/etc/auth > +@ctrnet-people::32767:32767::::::/usr/local/etc/auth > +@image-people::32767:32767::::::/usr/local/etc/auth > +@tnl-people::32767:32767::::::/usr/local/etc/auth > +@sgi-people::32767:32767::::::/usr/local/etc/auth > +@deleted1-people::32767:32767::::::/usr/local/etc/disabled > +@deleted2-people::32767:32767::::::/usr/local/etc/disabled > toybox> cat /etc/master.passwd root:8q0iQ8SRCw2/s:0:0::0:0:Charlie &:/root:/bin/csh kroot:8q0iQ8SRCw2/s:0:0::0:0:Charlie &:/root:/bin/ksh toor:*:0:0::0:0:Bourne-again Superuser:/root: daemon:*:1:31::0:0:Owner of many system processes:/root: operator:*:2:20::0:0:System &:/usr/guest/operator:/bin/csh bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent games:*:7:13::0:0:Games pseudo-user:/usr/games: news:*:8:8::0:0:News Subsystem:/:/nonexistent man:*:9:9::0:0:Mister Man Pages:/usr/share/man: uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/nonexistent nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/nonexistent +::::::::: > Okay, things to check: > > 1) Are you running kerberos? (probably not, but it's worth a shot. :) NO. (Yuck ;v) > 2) Did you upgrade to the SNAP by installing it fresh, or did you 'upgrade' > by installing over a previous version? Fresh. New filesystems and all... > 2a) If you 'upgraded,' did you make sure you have only one version of > libc.so.whatever in /usr/lib? N/A. > 3) Are you _SURE_ that you don't have an entry in your /etc/master.passwd > file that says +::0:0::::::? Maybe one you missed? No... see above. > 4) Are you _SURE_ they you ran pwd_mkdb after you edited > /etc/master.passwd? I never edited /etc/master.passwd. I only used vipw which is supposed to do this for me. For grins, I tried it. No difference... > 5) Did you re-run ldconfig after you installed the DES package? (Rebooting > accomplishes the same thing -- if you've rebooted the machine since the > DES package went in, the answer is 'yes.') I've reboot several times. > 6) If you do 'ldd /usr/bin/login' does it show it to be linking against > the correct version of libc.so.whatever? > > For reference, this is what it says for me: > > marple# ldd /usr/bin/login > /usr/bin/login: > -lutil.2 => /usr/lib/libutil.so.2.1 (0x801d000) > -lskey.2 => /usr/lib/libskey.so.2.0 (0x802c000) > -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8032000) > -lc.2 => /usr/lib/libc.so.2.2 (0x8047000) > toybox> ldd /usr/bin/login /usr/bin/login: -lutil.2 => /usr/lib/libutil.so.2.1 (0x801e000) -lskey.2 => /usr/lib/libskey.so.2.0 (0x802d000) -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8033000) -lc.2 => /usr/lib/libc.so.2.2 (0x8048000) This doesn't look right... but the program I built earlier looks OK. See below... why wouldn't the numbers match? > 6a) Also do an 'ldd test_program_you_built_earlier' and compare the > output with 'ldd /usr/bin/login'. toybox> ldd /home/sunc210/mikebo/tmp/pwtest /home/sunc210/mikebo/tmp/pwtest: -lutil.2 => /usr/lib/libutil.so.2.1 (0x801d000) -lskey.2 => /usr/lib/libskey.so.2.0 (0x802c000) -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8032000) -ldes.2 => /usr/lib/libdes.so.2.1 (0x8047000) -lc.2 => /usr/lib/libc.so.2.2 (0x8053000) > 7) Did you check /var/log/messages for suspicious messages resulting > from the failed login attempts? Yes, there were no suspicious messages. > 8) If you log in as root, can you do 'su mikebo?' su: no such login: mikebo > 8a) If so, if you then type 'whoami' does it say 'mikebo?' N/A. > > > Looks like NIS is working fine, and some programs/libraries are simply > > ignoring the fact that there are valid YP tokens in the passwd files. > > Well, all the references are either within libc, or inside a small number > of statically linked programs (e.g. those in /bin). I'm beginning to > suspect a libc mismatch of some kind. These are the C libraries I have > on my system: > > marple# ls -l /usr/lib/libc.* > -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a > -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2 > toybox> ls -l /usr/lib/libc.* -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 Now how did this happen? I installed via FTP from the default server listed in the install dialogue. toybox> cksum /usr/lib/libc.so.2.2 3292964480 435248 /usr/lib/libc.so.2.2 > (Note that I don't have the profiled libraries installed. This shouldn't > make any difference.) > > My libcrypt setup looks like this (sorry for the long lines): > > marple# ls -l /usr/lib/*crypt* > lrwxr-xr-x 1 bin bin 13 Jul 5 14:07 /usr/lib/libcrypt.a -> libdescrypt.a > lrwxr-xr-x 1 bin bin 18 Jul 5 14:07 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0 > lrwxr-xr-x 1 bin bin 15 Jul 5 14:07 /usr/lib/libcrypt_p.a -> libdescrypt_p.a > -r--r--r-- 1 bin bin 10690 Jun 28 04:47 /usr/lib/libdescrypt.a > -r--r--r-- 1 bin bin 18145 Jun 28 04:47 /usr/lib/libdescrypt.so.2.0 > -r--r--r-- 1 bin bin 12362 Jun 28 04:47 /usr/lib/libdescrypt_p.a > -r--r--r-- 1 bin bin 4576 Jun 28 04:47 /usr/lib/libscrypt.a > -r--r--r-- 1 bin bin 12755 Jun 28 04:47 /usr/lib/libscrypt.so.2.0 > toybox> ls -l /usr/lib/*crypt* lrwxr-xr-x 1 bin bin 13 Jul 3 12:51 /usr/lib/libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 bin bin 18 Jul 3 12:51 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 bin bin 15 Jul 3 12:51 /usr/lib/libcrypt_p.a -> libdescrypt_p.a -r--r--r-- 1 bin bin 10690 Jun 28 03:47 /usr/lib/libdescrypt.a -r--r--r-- 1 bin bin 18145 Jun 28 03:47 /usr/lib/libdescrypt.so.2.0 -r--r--r-- 1 bin bin 12362 Jun 28 03:47 /usr/lib/libdescrypt_p.a -r--r--r-- 1 bin bin 4576 Jun 28 03:47 /usr/lib/libscrypt.a -r--r--r-- 1 bin bin 12755 Jun 28 03:47 /usr/lib/libscrypt.so.2.0 -r--r--r-- 1 bin bin 5080 Jun 28 03:47 /usr/lib/libscrypt_p.a > > The DES package was installed at the same time as the install, and all > > appeared to complete flawlessly. The login program: > > toybox> ls -l /usr/bin/login > > -r-sr-xr-x 1 root bin 20480 Jun 28 03:59 /usr/bin/login > > toybox> cksum /usr/bin/login > > 957853657 20480 /usr/bin/login > > > > I appreciate all the help. What next? > > This depends on whether you did a complete reinstall or an upgrade. I did a complete install, including newfs of both / and /usr. > The reason I'm curious is this: I did change the getpwent(3) code in > libc rather substantially between the June 27th SNAP and the previous > one. Actually, what I did was sync the 2.1-STABLE version with the > 2.2-current version, which had survived for several weeks in the > -current tree without any trouble (no angry mobs came calling for my > head), so I moved it over. The newer version is a bit less messy than > the previous one and fixes some bugs. Also, /usr/include/pwd.h and > /usr/sbin/pwd_mkdb changed a little since they and getpwent(3) > are intimately related. > toybox> ls -l /usr/include/pwd.h /usr/sbin/pwd_mkdb -r--r--r-- 1 bin bin 4118 Jun 28 03:44 /usr/include/pwd.h -r-xr-xr-x 1 bin bin 12288 Jun 28 04:04 /usr/sbin/pwd_mkdb > The result is that if you somehow managed to keep an older version of > libc.so around (like from the previous SNAP) you might have conflicts since > the older getpwent(3) NIS code is not strictly forward compatible (the > new version is backward compatible though). Basically, if you use the > new pwd_mkdb to create a hash user database with NIS entries, the old > getpwent(3) will not be able to grok it properly. This sounds a lot like > what's happening here. > Indeed... again, I installed from scratch via FTP using the default server in the install dialogue. I can't remember the hostname, but I assume it's ftp.freebsd.org. Note that I do appear to have an older libc.so.2.2. Perhaps the install program screwed me up - but how? Thanks again for spending so much time. Regards, - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Mon Jul 8 20:03:12 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA29405 for bugs-outgoing; Mon, 8 Jul 1996 20:03:12 -0700 (PDT) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA29385 for ; Mon, 8 Jul 1996 20:03:08 -0700 (PDT) Received: from palmer.demon.co.uk (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-2) with ESMTP id EAA26775; Tue, 9 Jul 1996 04:02:46 +0100 (BST) To: mikebo@tellabs.com cc: wpaul@skynet.ctr.columbia.edu (Bill Paul), mikebo@freefall.freebsd.org (Mike Borowiec), bugs@FreeBSD.ORG From: "Gary Palmer" Subject: Re: 2.1-960627-SNAP: YP problem In-reply-to: Your message of "Mon, 08 Jul 1996 21:54:00 CDT." <199607090254.VAA21062@sunc210.tellabs.com> Date: Tue, 09 Jul 1996 04:02:45 +0100 Message-ID: <26773.836881365@palmer.demon.co.uk> Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk mikebo@tellabs.com wrote in message ID <199607090254.VAA21062@sunc210.tellabs.com>: > toybox> ls -l /usr/lib/libc.* > -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a > -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 > -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 > -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 > > Now how did this happen? I installed via FTP from the default > server listed in the install dialogue. You installed the compatability distributions (1.x and 2.0 by the looks of it). Sorry, I can't say much about the rest of your message :-) I'll leave that to Bill. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-bugs Mon Jul 8 20:08:41 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00388 for bugs-outgoing; Mon, 8 Jul 1996 20:08:41 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA00381; Mon, 8 Jul 1996 20:08:39 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0udT9k-0004fNC; Mon, 8 Jul 96 22:08 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id WAA21101; Mon, 8 Jul 1996 22:07:32 -0500 Message-Id: <199607090307.WAA21101@sunc210.tellabs.com> Subject: Re: 2.1-960627-SNAP: YP problem To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Mon, 8 Jul 1996 22:07:32 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@FreeBSD.ORG In-Reply-To: <26773.836881365@palmer.demon.co.uk> from "Gary Palmer" at Jul 9, 96 04:02:45 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Gary wrote: > mikebo@tellabs.com wrote in message ID > <199607090254.VAA21062@sunc210.tellabs.com>: > > toybox> ls -l /usr/lib/libc.* > > -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a > > -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 > > -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 > > -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 > > > > Now how did this happen? I installed via FTP from the default > > server listed in the install dialogue. > > You installed the compatability distributions (1.x and 2.0 by the > looks of it). Sorry, I can't say much about the rest of your message > :-) I'll leave that to Bill. > Installing compatibility options should install the 1.1 and 2.0 libs, but shouldn't trash the 2.2 lib, should it? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Mon Jul 8 20:10:56 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00724 for bugs-outgoing; Mon, 8 Jul 1996 20:10:56 -0700 (PDT) Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA00709 for ; Mon, 8 Jul 1996 20:10:52 -0700 (PDT) Received: from palmer.demon.co.uk (localhost [127.0.0.1]) by palmer.demon.co.uk (sendmail/PALMER-2) with ESMTP id EAA26832; Tue, 9 Jul 1996 04:10:43 +0100 (BST) To: mikebo@tellabs.com cc: bugs@FreeBSD.ORG From: "Gary Palmer" Subject: Re: 2.1-960627-SNAP: YP problem In-reply-to: Your message of "Mon, 08 Jul 1996 22:07:32 CDT." <199607090307.WAA21101@sunc210.tellabs.com> Date: Tue, 09 Jul 1996 04:10:42 +0100 Message-ID: <26830.836881842@palmer.demon.co.uk> Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk mikebo@tellabs.com wrote in message ID <199607090307.WAA21101@sunc210.tellabs.com>: > Installing compatibility options should install the 1.1 and 2.0 libs, > but shouldn't trash the 2.2 lib, should it? Sorry, I must have missed something ... what makes you think your libc.so.2.2 is trashed? Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-bugs Mon Jul 8 20:13:37 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01075 for bugs-outgoing; Mon, 8 Jul 1996 20:13:37 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA01056 for ; Mon, 8 Jul 1996 20:13:32 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id UAA06090; Mon, 8 Jul 1996 20:12:26 -0700 (PDT) To: mikebo@tellabs.com cc: wpaul@skynet.ctr.columbia.edu (Bill Paul), mikebo@freefall.freebsd.org (Mike Borowiec), bugs@freebsd.org Subject: Re: 2.1-960627-SNAP: YP problem In-reply-to: Your message of "Mon, 08 Jul 1996 21:54:00 CDT." <199607090254.VAA21062@sunc210.tellabs.com> Date: Mon, 08 Jul 1996 20:12:26 -0700 Message-ID: <6088.836881946@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Indeed... again, I installed from scratch via FTP using the default > server in the install dialogue. I can't remember the hostname, but I > assume it's ftp.freebsd.org. Note that I do appear to have an older > libc.so.2.2. Perhaps the install program screwed me up - but how? Well, if you picked one of the canned user distributions then it selected COMPAT_* on your behalf. Perhaps you want to try a Custom set? Jordan From owner-freebsd-bugs Mon Jul 8 20:16:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01273 for bugs-outgoing; Mon, 8 Jul 1996 20:16:06 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA01228; Mon, 8 Jul 1996 20:15:57 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id UAA06134; Mon, 8 Jul 1996 20:15:17 -0700 (PDT) To: mikebo@tellabs.com cc: gpalmer@FreeBSD.ORG (Gary Palmer), mikebo@freefall.freebsd.org (Mike Borowiec), bugs@FreeBSD.ORG Subject: Re: 2.1-960627-SNAP: YP problem In-reply-to: Your message of "Mon, 08 Jul 1996 22:07:32 CDT." <199607090307.WAA21101@sunc210.tellabs.com> Date: Mon, 08 Jul 1996 20:15:16 -0700 Message-ID: <6131.836882116@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Installing compatibility options should install the 1.1 and 2.0 libs, > but shouldn't trash the 2.2 lib, should it? No, and it didn't. What makes you think that it did? Jordan From owner-freebsd-bugs Mon Jul 8 20:38:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA03608 for bugs-outgoing; Mon, 8 Jul 1996 20:38:03 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA03593 for ; Mon, 8 Jul 1996 20:37:58 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0udTc7-0004fHC; Mon, 8 Jul 96 22:37 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id WAA21151; Mon, 8 Jul 1996 22:36:51 -0500 Message-Id: <199607090336.WAA21151@sunc210.tellabs.com> Subject: Re: 2.1-960627-SNAP: YP problem To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 8 Jul 1996 22:36:49 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org In-Reply-To: <6131.836882116@time.cdrom.com> from "Jordan K. Hubbard" at Jul 8, 96 08:15:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan, et al. wrote: > > > Installing compatibility options should install the 1.1 and 2.0 libs, > > but shouldn't trash the 2.2 lib, should it? > > No, and it didn't. What makes you think that it did? > 'Cuz Gary wrote: > The result is that if you somehow managed to keep an older version of > libc.so around (like from the previous SNAP) you might have conflicts since > the older getpwent(3) NIS code is not strictly forward compatible and his libc.so.2.2 has a newer date (by several months), and is bigger (by a few hundred bytes). If this doesn't this mean I have an out-of-date libc.so.2.2, it's at least *different* than Gary Palmer's "reference" box. How exactly it's different I don't know, but an April libc in a July SNAP is kinda suspicious, no? > marple# ls -l /usr/lib/libc.* > -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a > -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2 toybox> ls -l /usr/lib/libc.* -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 Please excuse me if I'm making no sense... I've been at work since 0800 and it's now 2230. I guess I'm grasping for anything that might explain my NIS woes. Regards, - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Mon Jul 8 21:32:00 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA10929 for bugs-outgoing; Mon, 8 Jul 1996 21:32:00 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA10914 for ; Mon, 8 Jul 1996 21:31:54 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id AAA18230; Tue, 9 Jul 1996 00:30:29 -0400 From: Bill Paul Message-Id: <199607090430.AAA18230@skynet.ctr.columbia.edu> Subject: Re: 2.1-960627-SNAP: YP problem To: mikebo@tellabs.com Date: Tue, 9 Jul 1996 00:30:28 -0400 (EDT) Cc: bugs@freebsd.org In-Reply-To: <199607090336.WAA21151@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 8, 96 10:36:49 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, mikebo@tellabs.com had to walk into mine and say: > Jordan, et al. wrote: > > > > > Installing compatibility options should install the 1.1 and 2.0 libs, > > > but shouldn't trash the 2.2 lib, should it? > > > > No, and it didn't. What makes you think that it did? > > > 'Cuz Gary wrote: Uh, I'm Bill, not Gary. :) > > The result is that if you somehow managed to keep an older version of > > libc.so around (like from the previous SNAP) you might have conflicts since > > the older getpwent(3) NIS code is not strictly forward compatible > > and his libc.so.2.2 has a newer date (by several months), and is bigger > (by a few hundred bytes). If this doesn't this mean I have an out-of-date > libc.so.2.2, it's at least *different* than Gary Palmer's "reference" box. > How exactly it's different I don't know, but an April libc in a July SNAP > is kinda suspicious, no? > > > marple# ls -l /usr/lib/libc.* > > -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a > > -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2 Notice also that the timestamps on both my libraries match. In your case, libc.so.2.2 and libc.a should match but they don't. (Your libc.a looks correct however.) > toybox> ls -l /usr/lib/libc.* > -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a > -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 > -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 > -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 > > Please excuse me if I'm making no sense... I've been at work since > 0800 and it's now 2230. I guess I'm grasping for anything that might > explain my NIS woes. I think you do have a bogus libc.so.2.2, however I can't explain how you got it. The compat distribution is supposed to add the two older libraries (I guess) not replace the 'standard' one. (Note that I did do a custom install on my box: I specifically selected the bin, man, games, dict and des distributions and nothing else. Anyway, here's how you can try to fix this: get the bin distribution (bin.aa through bin.whatever) and extract the libc.so.2.2 from there. The distribution is basically one giant tar.gz archive. You can extract a single file from it like this: % cat bin.?? | gzip -d | tar -xf - usr/lib/libc.so.2.2 Replace your existing libc.so.2.2 with this one (this is best done from single user mode) and then see if NIS works. Ideally, it should. I still can't figure out how the test program seemed to work before though. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." ============================================================================= From owner-freebsd-bugs Mon Jul 8 21:45:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA12155 for bugs-outgoing; Mon, 8 Jul 1996 21:45:05 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA12147 for ; Mon, 8 Jul 1996 21:45:02 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0udUf1-0004fKC; Mon, 8 Jul 96 23:44 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id XAA21244; Mon, 8 Jul 1996 23:43:55 -0500 Message-Id: <199607090443.XAA21244@sunc210.tellabs.com> Subject: Re: 2.1-960627-SNAP: YP problem To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 8 Jul 1996 23:43:55 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org In-Reply-To: <199607090430.AAA18230@skynet.ctr.columbia.edu> from "Bill Paul" at Jul 9, 96 00:30:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill - You wrote: > Uh, I'm Bill, not Gary. :) > Sorry... I told ya I was tired! ;v) > > > marple# ls -l /usr/lib/libc.* > > > -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a > > > -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2 > > Notice also that the timestamps on both my libraries match. In > your case, libc.so.2.2 and libc.a should match but they don't. (Your > libc.a looks correct however.) > > > toybox> ls -l /usr/lib/libc.* > > -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a > > -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 > > -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 > > -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 > > > I think you do have a bogus libc.so.2.2, however I can't explain how > you got it. The compat distribution is supposed to add the two older > libraries (I guess) not replace the 'standard' one. (Note that I did > do a custom install on my box: I specifically selected the bin, man, > games, dict and des distributions and nothing else. > I did a custom install also. Perhaps Jordan can shed some light here? > Anyway, here's how you can try to fix this: get the bin distribution > (bin.aa through bin.whatever) and extract the libc.so.2.2 from there. > The distribution is basically one giant tar.gz archive. You can > extract a single file from it like this: > > % cat bin.?? | gzip -d | tar -xf - usr/lib/libc.so.2.2 > > Replace your existing libc.so.2.2 with this one (this is best done > from single user mode) and then see if NIS works. Ideally, it should. > > I still can't figure out how the test program seemed to work before > though. > Yes, it still works... I don't get it. But hey, if I got a bogus libc.so then what the heck else is fouled up? Basically, I no longer trust this installation. I may blow it away... Jordan, if you want me to run anything against my system before I blow it away (in case you were curious as to how the installation gave me a bogus libc.so) just ask, but soon. ;v) - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Tue Jul 9 00:24:12 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA09435 for bugs-outgoing; Tue, 9 Jul 1996 00:24:12 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA09428 for ; Tue, 9 Jul 1996 00:24:05 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id AAA06740; Tue, 9 Jul 1996 00:22:06 -0700 (PDT) To: mikebo@tellabs.com cc: wpaul@skynet.ctr.columbia.edu (Bill Paul), mikebo@freefall.freebsd.org (Mike Borowiec), bugs@freebsd.org Subject: Re: 2.1-960627-SNAP: YP problem In-reply-to: Your message of "Mon, 08 Jul 1996 23:43:55 CDT." <199607090443.XAA21244@sunc210.tellabs.com> Date: Tue, 09 Jul 1996 00:22:06 -0700 Message-ID: <6738.836896926@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Jordan, if you want me to run anything against my system before I > blow it away (in case you were curious as to how the installation > gave me a bogus libc.so) just ask, but soon. ;v) Not necessary - you're on the 2.2 track and I'm not really dealing with problems there until 2.1.5 is out the door, so don't wait on me here.. :-) Jordan From owner-freebsd-bugs Tue Jul 9 02:40:07 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA23563 for bugs-outgoing; Tue, 9 Jul 1996 02:40:07 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA23518; Tue, 9 Jul 1996 02:40:03 -0700 (PDT) Resent-Date: Tue, 9 Jul 1996 02:40:03 -0700 (PDT) Resent-Message-Id: <199607090940.CAA23518@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, zach@blizzard.gaffaneys.com Received: from freebsd.gaffaneys.com ([134.129.252.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22846 for ; Tue, 9 Jul 1996 02:30:09 -0700 (PDT) Received: (from zach@localhost) by freebsd.gaffaneys.com (8.6.12/8.6.12) id EAA05222; Tue, 9 Jul 1996 04:31:02 -0500 Message-Id: <199607090931.EAA05222@freebsd.gaffaneys.com> Date: Tue, 9 Jul 1996 04:31:02 -0500 From: zach@blizzard.gaffaneys.com Reply-To: zach@blizzard.gaffaneys.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/1377: Possible security hole in mv(1) Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1377 >Category: bin >Synopsis: mv(1) retains the setuid bit when it is unable to preserve the uid. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jul 9 02:40:01 PDT 1996 >Last-Modified: >Originator: Zach Heilig >Organization: Zach Heilig (zach@blizzard.gaffaneys.com) >Release: FreeBSD 2.1.0-RELEASE i386 >Environment: FreeBSD 2.1.0-RELEASE >Description: mv(1) will retain the setuid bit on a file when it is unable to preserve the uid. This would, for example, allow one user to create a setuid executable, and if they should somehow convince a different user to mv(1) it to a different filesystem, they have access to that users account. mv(1) should not retain either the setuid or setgid bits when it is unable to preserve both the uid and the gid of the file. This would bring it in line with cp(1) which mv(1) is theoretically supposed to be using. I would track it down, but I don't have the mv(1) source online. >How-To-Repeat: Script started on Tue Jul 9 03:50:45 1996 $ whoami user1 $ pwd /usr/home/user1 $ mkdir foo $ chmod 777 foo $ cd foo $ touch bar $ chmod 6755 bar $ ls -l bar -rwsr-sr-x 1 user1 user 0 Jul 9 03:51 bar $ exit Script done on Tue Jul 9 03:51:14 1996 Script started on Tue Jul 9 03:51:24 1996 $ whoami user2 $ cd /tmp $ mv ~user1/foo/bar . mv: ./bar: set owner/group: Operation not permitted mv: ./bar: set mode: Operation not permitted $ ls -l bar -rwsr-xr-x 1 user2 wheel 0 Jul 9 03:51 bar $ exit Script done on Tue Jul 9 03:51:39 1996 >Fix: >Audit-Trail: >Unformatted: sw-bug From owner-freebsd-bugs Tue Jul 9 03:17:46 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25640 for bugs-outgoing; Tue, 9 Jul 1996 03:17:46 -0700 (PDT) Received: from freebsd.gaffaneys.com ([134.129.252.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA25630 for ; Tue, 9 Jul 1996 03:17:42 -0700 (PDT) Received: (from zach@localhost) by freebsd.gaffaneys.com (8.6.12/8.6.12) id FAA05263; Tue, 9 Jul 1996 05:18:05 -0500 To: Bruce Evans Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1375: Extraneous warning from mv(1) References: <199607080830.BAA16658@freefall.freebsd.org> From: Zach Heilig Date: 09 Jul 1996 05:18:04 -0500 In-Reply-To: Bruce Evans's message of Mon, 8 Jul 1996 01:30:07 -0700 (PDT) Message-ID: <8720ilafxf.fsf@freebsd.gaffaneys.com> Lines: 40 X-Mailer: Gnus v5.2.32/Emacs 19.31 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: > >According to mv(1), moving a file across filesystems is equivalent to > >calling cp -pRP, surrounded by calls to rm(1). According to cp(1), > >when the -p option is used, no error message should be displayed if > >the user and group ID of the file cannot be preserved. > This is probably a bug in mv.1. mv should and does try harder than > cp to preserve attributes. But why should I, as a user, care.. as long as the setuid/setgid bits and the group write bit are not set, it doesn't really make that much difference. In fact, the user should not be notified of errors that are not of significance, as they might then ignore significant ones, for example: mv: ./bar: set owner/group: Operation not permitted looks very similar to: mv: ./bar: set mode: Operation not permitted when you just know that any messages from mv(1) don't mean anything to you. See my problem report for what currently happens when you see a message like the second (it is very bad). Who knows what other bugs are out there that users might notice if they weren't ignoring extraneous output. > >mv(1) behaves as expected if the file and its destination directory > >are on the same filesystem, or if a directory is moved across a > >filesystem instead of a file. > The latter is a bug in mv. It really does use cp -pRP in this case, > but cp -pRP is inadequate. It snaps links, doesn't preserve preservable > directory timestamps, and does the wrong thing for `mv dir existing-dir'. -- Zach Heilig (zach@blizzard.gaffaneys.com) Support bacteria -- it's the only culture some people have! ALL unsolicited >commercial< email is subject to a $100 proof-reading fee. From owner-freebsd-bugs Tue Jul 9 08:19:39 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA15747 for bugs-outgoing; Tue, 9 Jul 1996 08:19:39 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA15742 for ; Tue, 9 Jul 1996 08:19:36 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0udeZ6-0004fOC; Tue, 9 Jul 96 10:19 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id KAA21958; Tue, 9 Jul 1996 10:18:28 -0500 Message-Id: <199607091518.KAA21958@sunc210.tellabs.com> Subject: Re: 2.1-960627-SNAP: YP problem To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 9 Jul 1996 10:18:27 -0500 (CDT) Cc: bugs@freebsd.org, mikebo (Mike Borowiec) In-Reply-To: <6738.836896926@time.cdrom.com> from "Jordan K. Hubbard" at Jul 9, 96 00:22:06 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan - You wrote: > > Jordan, if you want me to run anything against my system before I > > blow it away (in case you were curious as to how the installation > > gave me a bogus libc.so) just ask, but soon. ;v) > > Not necessary - you're on the 2.2 track and I'm not really dealing > with problems there until 2.1.5 is out the door, so don't wait on me > here.. :-) > Ummm.... I'm confused. I thought 2.1-960627-SNAP *was* 2.1.5 Beta 1. I thought I was doing a 2.1.5 Beta 1 install. Didn't I? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Tue Jul 9 10:10:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22380 for bugs-outgoing; Tue, 9 Jul 1996 10:10:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22370; Tue, 9 Jul 1996 10:10:02 -0700 (PDT) Resent-Date: Tue, 9 Jul 1996 10:10:02 -0700 (PDT) Resent-Message-Id: <199607091710.KAA22370@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, obrien@Nuxi.cs.ucdavis.edu Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA22077 for ; Tue, 9 Jul 1996 10:04:17 -0700 (PDT) Received: (from obrien@localhost) by relay.nuxi.com (8.6.12/8.6.12) id KAA00901; Tue, 9 Jul 1996 10:04:24 -0700 Message-Id: <199607091704.KAA00901@relay.nuxi.com> Date: Tue, 9 Jul 1996 10:04:24 -0700 From: "David E. O'Brien" Reply-To: obrien@Nuxi.cs.ucdavis.edu To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/1378: sgmlfmt generated freebsd-faq.tex does not LaTeX Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1378 >Category: docs >Synopsis: sgmlfmt generated freebsd-faq.tex does not LaTeX >Confidential: yes >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Tue Jul 9 10:10:01 PDT 1996 >Last-Modified: >Originator: David E. O'Brien >Organization: University of California, Davis >Release: FreeBSD 2.1.0-RELEASE tools, -current FAQ source file >Environment: Using sgmlfmt and LaTeX 2e package from 2.1-RELEASE >Description: The freebsd-faq.tex file generated by sgmlfmt is not LaTeX'able. The problem line in the sgml file is: Enter [ the kernel goes into configuration mode ] Disable t l.1799 [ the kernel goes into configuration mode ] ? The problem is LaTeX doesn't like the ``['' and ``]''. I manually fixed it by changing ``['' to ``\['' or ``(''. >How-To-Repeat: sgmlfmt -f latex freebsd-faq.sgm latex freebsd-faq.tex >Fix: Don't know any sgml. Sorry. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Jul 9 16:08:37 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16609 for bugs-outgoing; Tue, 9 Jul 1996 16:08:37 -0700 (PDT) Received: (from gpalmer@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16592; Tue, 9 Jul 1996 16:08:36 -0700 (PDT) Date: Tue, 9 Jul 1996 16:08:36 -0700 (PDT) From: Gary Palmer Message-Id: <199607092308.QAA16592@freefall.freebsd.org> To: obrien@Nuxi.cs.ucdavis.edu, gpalmer, freebsd-bugs Subject: Re: docs/1378 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: sgmlfmt generated freebsd-faq.tex does not LaTeX State-Changed-From-To: open-closed State-Changed-By: gpalmer State-Changed-When: Tue Jul 9 16:06:26 PDT 1996 State-Changed-Why: James Raynard says he fixed this in rev. 1.51 of freebsd-faq.sgml From owner-freebsd-bugs Tue Jul 9 16:09:10 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16660 for bugs-outgoing; Tue, 9 Jul 1996 16:09:10 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA16654 for ; Tue, 9 Jul 1996 16:09:05 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id JAA09150; Wed, 10 Jul 1996 09:03:05 +1000 Date: Wed, 10 Jul 1996 09:03:05 +1000 From: Bruce Evans Message-Id: <199607092303.JAA09150@godzilla.zeta.org.au> To: bde@zeta.org.au, zach@blizzard.gaffaneys.com Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> This is probably a bug in mv.1. mv should and does try harder than >> cp to preserve attributes. >But why should I, as a user, care.. as long as the setuid/setgid bits Some users might care. E.g., if the file is supposed to have a particular gid so that everyone in the group can access it, then mv'ing it across file systems will break group accessibility even if you put it back. Try this: touch /tmp/z # gid is same as /tmp (bin) mv /tmp/z ~ # gid gets clobbered to your gid mv ~/z /tmp # gid is still yours, not bin mv cannot know if the user cares, so it shouldn't silently drop attributes. I now think it should refuse to the move if it can't preserve all the attributes. It can simply unlink the target and avoid unlinking the source if there is a problem. The problem is much more complicated for moving entire trees. Is mv supposed to successfully move the entire tree before unlinking anything in the original tree and then check that all unlinks would succeed before unlinking anything? I think it should. Otherwise an error leaves both the source and target trees in a mess. Try this: mkdir /tmp/z mkdir /tmp/z/a touch /tmp/z/b /tmp/z/c /tmp/z/a/d /tmp/z/a/e su chown root /tmp/z/a /tmp/z/c /tmp/z/a/e exit mv /tmp/z ~ This gives suitable error messages for not being able to move /tmp/z/a or its contents. It silently moves /tmp/z/c and loses its uid. The target tree ends up with all the files from the source tree (everything is readable so there is no problem copying it) and everything possible got removed from the original tree because the `cp -pRP' step succeeded although it didn't preserve one uid. Messes like this are easy to create using cp -pRP and rm -rf explicitly :-). mv across file systems is of negative worth unless it does a better job of makeing the move atomic. Bruce From owner-freebsd-bugs Tue Jul 9 16:10:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16776 for bugs-outgoing; Tue, 9 Jul 1996 16:10:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16762; Tue, 9 Jul 1996 16:10:02 -0700 (PDT) Resent-Date: Tue, 9 Jul 1996 16:10:02 -0700 (PDT) Resent-Message-Id: <199607092310.QAA16762@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, max@sfc.wide.ad.jp Received: from mail.tky007.tth.expo96.ad.jp (root@tky007.tth.expo96.ad.jp [133.246.32.58]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA15841 for ; Tue, 9 Jul 1996 16:00:34 -0700 (PDT) Received: (from masafumi@localhost) by mail.tky007.tth.expo96.ad.jp (8.7.5/3.4W4-SMTP) id HAA25766; Wed, 10 Jul 1996 07:59:59 +0900 (JST) Message-Id: <199607092259.HAA25766@mail.tky007.tth.expo96.ad.jp> Date: Wed, 10 Jul 1996 07:59:59 +0900 (JST) From: Masafumi NAKANE Reply-To: max@sfc.wide.ad.jp To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: gnu/1379: Man command problem, when it writes into symlinked dir Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1379 >Category: gnu >Synopsis: Man command problem, when it writes into symlinked dir >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jul 9 16:10:01 PDT 1996 >Last-Modified: >Originator: Masafumi NAKANE >Organization: >Release: FreeBSD 2.2-CURRENT i386 >Environment: This problem occurs on FreeBSD-current with CTM deltas up to src-cur.1973 applied. >Description: The man command doesn't check the owner of the symbolic link when it writes the formatted man page out to symlinked cat? directory. This makes it possible for non-super-user to populate /usr/share/man/cat? directories (or any directories owned by the user man) with junk and/or replace existing pre-formatted man pages with meangless files. >How-To-Repeat: % setenv MANPATH $HOME/man % mkdir $HOME/man % mkdir $HOME/man/man1 % ln -s /usr/share/man/cat1 $HOME/man/cat1 % touch $HOME/man/man1/whatever.1 % man whatever >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Jul 9 16:40:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA18264 for bugs-outgoing; Tue, 9 Jul 1996 16:40:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA18238; Tue, 9 Jul 1996 16:40:01 -0700 (PDT) Date: Tue, 9 Jul 1996 16:40:01 -0700 (PDT) Message-Id: <199607092340.QAA18238@freefall.freebsd.org> To: freebsd-bugs Cc: From: James Raynard Subject: Re: docs/1378: sgmlfmt generated freebsd-faq.tex does not LaTeX Reply-To: James Raynard Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR docs/1378; it has been noted by GNATS. From: James Raynard To: FreeBSD-gnats@freefall.freebsd.org, obrien@nuxi.cs.ucdavis.edu Cc: Subject: Re: docs/1378: sgmlfmt generated freebsd-faq.tex does not LaTeX Date: Tue, 9 Jul 1996 20:23:52 GMT >>>>> "David E. O'Brien" writes: > > The freebsd-faq.tex file generated by sgmlfmt is not LaTeX'able. > The problem line in the sgml file is: > > Enter > [ the kernel goes into configuration mode ] > Disable Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, Received:"from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA22966 for" ; Tue, 9 Jul 1996 18:19:55.-0700 (PDT) Received: from zombie.ncsc.mil (zombie.ncsc.mil [144.51.15.1]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id SAA07407 for ; Tue, 9 Jul 1996 18:19:38 -0700 Received: (from sjr@localhost) by zombie.ncsc.mil (8.6.11/8.6.11) id VAA13250 for FreeBSD-gnats-submit@freebsd.org; Tue, 9 Jul 1996 21:18:02 -0400 Message-Id: <199607100118.VAA13250@zombie.ncsc.mil> Date: Tue, 9 Jul 1996 21:18:02 -0400 From: "Stephen J. Roznowski" To: FreeBSD-gnats-submit@freebsd.org Subject: misc/1380: Year 2000 breakage with tm_year Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1380 >Category: misc >Synopsis: Year 2000 breakage with tm_year >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jul 9 18:20:01 PDT 1996 >Last-Modified: >Originator: Stephen J. Roznowski >Organization: >Release: FreeBSD 2.2-960612-SNAP i386 >Environment: >Description: Several programs have a hardcoded 19 in responses for the year. This will break in 4 years... This was fixed in NetBSD as PR misc/2308. (I think that I have the same changes as were finally committed) >How-To-Repeat: find /usr/src -type f -print | xargs grep '19%' >Fix: As I stated in the NetBSD PR: "There is also similiar code in "gnu/usr.bin/rcs/lib/rcstime.c", but I'm less sure of the proper fix there." *** usr.bin/yacc/test/ftp.tab.c.orig Tue Jul 9 16:57:53 1996 --- usr.bin/yacc/test/ftp.tab.c Tue Jul 9 17:00:13 1996 *************** *** 1467,1474 **** struct tm *gmtime(); t = gmtime(&stbuf.st_mtime); reply(213, ! "19%02d%02d%02d%02d%02d%02d", ! t->tm_year, t->tm_mon+1, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec); } } --- 1467,1474 ---- struct tm *gmtime(); t = gmtime(&stbuf.st_mtime); reply(213, ! "%04d%02d%02d%02d%02d%02d", ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec); } } *** usr.bin/yacc/test/ftp.y.orig Tue Jul 9 16:59:03 1996 --- usr.bin/yacc/test/ftp.y Tue Jul 9 16:59:33 1996 *************** *** 455,462 **** struct tm *gmtime(); t = gmtime(&stbuf.st_mtime); reply(213, ! "19%02d%02d%02d%02d%02d%02d", ! t->tm_year, t->tm_mon+1, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec); } } --- 455,462 ---- struct tm *gmtime(); t = gmtime(&stbuf.st_mtime); reply(213, ! "%04d%02d%02d%02d%02d%02d", ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec); } } *** libexec/ftpd/ftpcmd.y.orig Tue Jul 9 17:00:30 1996 --- libexec/ftpd/ftpcmd.y Tue Jul 9 17:00:49 1996 *************** *** 491,498 **** struct tm *t; t = gmtime(&stbuf.st_mtime); reply(213, ! "19%02d%02d%02d%02d%02d%02d", ! t->tm_year, t->tm_mon+1, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec); } } --- 491,498 ---- struct tm *t; t = gmtime(&stbuf.st_mtime); reply(213, ! "%04d%02d%02d%02d%02d%02d", ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec); } } *** usr.bin/make/targ.c.orig Tue Jul 9 17:01:00 1996 --- usr.bin/make/targ.c Tue Jul 9 17:01:22 1996 *************** *** 467,475 **** parts = localtime(&time); ! sprintf (buf, "%d:%02d:%02d %s %d, 19%d", parts->tm_hour, parts->tm_min, parts->tm_sec, ! months[parts->tm_mon], parts->tm_mday, parts->tm_year); return(buf); } --- 467,475 ---- parts = localtime(&time); ! sprintf (buf, "%d:%02d:%02d %s %d, %d", parts->tm_hour, parts->tm_min, parts->tm_sec, ! months[parts->tm_mon], parts->tm_mday, 1900+parts->tm_year); return(buf); } *** gnu/usr.sbin/isdn/load/load.c.orig Tue Jul 9 17:18:28 1996 --- gnu/usr.sbin/isdn/load/load.c Tue Jul 9 17:18:56 1996 *************** *** 71,78 **** tt = time(NULL); t = localtime(&tt); ! sprintf(buf, "%.2d%.2d%.2d%.2d%.2d19%.2d", t->tm_hour, ! t->tm_min, t->tm_sec, t->tm_mday, t->tm_mon + 1, t->tm_year); if (ioctl(f, NICCY_SET_CLOCK, buf) < 0) { --- 71,78 ---- tt = time(NULL); t = localtime(&tt); ! sprintf(buf, "%.2d%.2d%.2d%.2d%.2d%.4d", t->tm_hour, ! t->tm_min, t->tm_sec, t->tm_mday, t->tm_mon + 1, 1900+t->tm_year); if (ioctl(f, NICCY_SET_CLOCK, buf) < 0) { *** gnu/usr.sbin/isdn/misc/stime.c.orig Tue Jul 9 17:19:09 1996 --- gnu/usr.sbin/isdn/misc/stime.c Tue Jul 9 17:19:24 1996 *************** *** 38,45 **** } tt = time(NULL); t = localtime(&tt); ! sprintf(buf, "%.2d%.2d%.2d%.2d%.2d19%.2d", t->tm_hour, ! t->tm_min, t->tm_sec, t->tm_mday, t->tm_mon + 1, t->tm_year); if (ioctl(f, NICCY_SET_CLOCK, buf) < 0) { --- 38,45 ---- } tt = time(NULL); t = localtime(&tt); ! sprintf(buf, "%.2d%.2d%.2d%.2d%.2d%.4d", t->tm_hour, ! t->tm_min, t->tm_sec, t->tm_mday, t->tm_mon + 1, 1900+t->tm_year); if (ioctl(f, NICCY_SET_CLOCK, buf) < 0) { >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Jul 9 18:49:39 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA24906 for bugs-outgoing; Tue, 9 Jul 1996 18:49:39 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA24896 for ; Tue, 9 Jul 1996 18:49:36 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id BAA02023; Wed, 10 Jul 1996 01:49:15 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma002019; Wed Jul 10 01:48:52 1996 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id SAA28951; Tue, 9 Jul 1996 18:48:52 -0700 Date: Tue, 9 Jul 1996 18:48:52 -0700 From: "M.R.Murphy" Message-Id: <199607100148.SAA28951@meerkat.mole.org> To: bde@zeta.org.au, zach@blizzard.gaffaneys.com Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > mv cannot know if the user cares, so it shouldn't silently drop > attributes. I now think it should refuse to the move if it can't > preserve all the attributes. It can simply unlink the target and > avoid unlinking the source if there is a problem. Or, one could leave it as it is, and accept the known, rather predictable, and simple behavior instead of a more complicated and unknown behavior. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good. If it ain't broke, don't fix it. From owner-freebsd-bugs Tue Jul 9 20:17:07 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01369 for bugs-outgoing; Tue, 9 Jul 1996 20:17:07 -0700 (PDT) Received: from minotaur.labyrinth.net.au (minotaur.labyrinth.net.au [203.9.148.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA01349 for ; Tue, 9 Jul 1996 20:16:51 -0700 (PDT) Received: (from mail@localhost) by minotaur.labyrinth.net.au (8.7.2/8.7.2) id NAA25059 for ; Wed, 10 Jul 1996 13:16:11 +1000 (EST) Date: Wed, 10 Jul 1996 13:16:11 +1000 (EST) Message-Id: <199607100316.NAA25059@minotaur.labyrinth.net.au> X-Authentication-Warning: minotaur.labyrinth.net.au: mail set sender to using -f Received: from portal-as8.labyrinth.net.au(203.9.148.18) by minotaur.labyrinth.net.au via smap (V1.3) id sma025046; Wed Jul 10 13:15:42 1996 X-Sender: jbh@labyrinth.net.au (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bugs@freebsd.org From: John Hartley Subject: tandberg scsi tape + FreeBSD 2.1/2.0.5 Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Following is a copy of message posted onto *.freebsd.misc new group re: Problem with tandberg 4100 scsi tape. I have not had any suggestion which have provide a solution to my problem and so am posting this bug report. >I have been trying to get a tandberg 4100 scsi tape >drive running so far unsuccessfully. >My configuration is: >IBM 350/DX4-100 32 MB Adaptec 2940 SCSI controller, >Fujitsu HD scsi 0 >Matshita CD-ROM scsi 1 >Tandberg TDC 4100 scsi 3 Now changed to 2 following mailed suggestion!! > >The tape is recognised at boot as follows: >(ahc0:3:0): "TANDBERG TDC 4100 J04" Type 1 removeable SCSI 2 >st(shc0:3:0): Sequential-Access density code 0x0, 512-byte blocks > >all operations done on the tape drive result in the following type of message: > >st0(ahc0:3:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field > replacement unit: 2 >st0: Cannot set selected mode st0: oops not queued > >I have tried a number of suggestions all of which fail with the same codes: >these include: >mt -f /dev/st0ctl.0 density 0x11 >mt -f /dev/st0ctl.0 blocksize 512 > >It has been suggested that the firmware version is the problem, however >the unit works fine with Windows NT and DOS tar for ASPI. > >I have recompiled the kernel with the SCSIDEBUG option on, but all the >scsi commands produce a simillar error: >scsi -f /dev/rst0 -d 0x10 >produces: >st0(ahc0:3:0): ILLEGAL REQUEST csi ..... > >I have read many articles in the various archives reporting simillar problems >but no statement of the solution. One suggestion was to >"just set the tape to SCSI-1 mode". How is this done? >I have tried with the tape in during boot and out, it makes no difference. >Can some witch doctor please advise or provide further suggestions for >how to de-hex my cursed tape unit ;-) . > >Thanks in advance. > >John Hartley >Graphica Softare Pty. Ltd. inet: jbh@labyrinth.net.au >North Fitzroy, Victoria fax: + 61 3 9481-1520 > Following are copies of my /var/log/messages log file: The tape error message occur for all operations on the /dev/rst0 device ie tar, mt, dd etc The kernel has been compiled with SCSIDEBUG option set and with 2 3COM etherlink III cards. Jul 10 11:46:49 qwiff /kernel: FreeBSD 2.1.0-RELEASE #0: Sat Jul 6 21:14:24 1996 Jul 10 11:46:49 qwiff /kernel: jbh@qwiff.graphica.com.au:/usr/src/sys/compile/TP_SIMPLE Jul 10 11:46:50 qwiff /kernel: CPU: i486 DX4 (486-class CPU) Jul 10 11:46:50 qwiff /kernel: Origin = "GenuineIntel" Id = 0x480 Stepping=0 Jul 10 11:46:50 qwiff /kernel: Features=0x3 Jul 10 11:46:50 qwiff /kernel: real memory = 33554432 (32768K bytes) Jul 10 11:46:50 qwiff /kernel: avail memory = 31035392 (30308K bytes) Jul 10 11:46:50 qwiff /kernel: Probing for devices on the ISA bus: Jul 10 11:46:50 qwiff /kernel: sc0 at 0x60-0x6f irq 1 on motherboard Jul 10 11:46:51 qwiff /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> Jul 10 11:46:51 qwiff /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Jul 10 11:46:51 qwiff /kernel: sio0: type 16550A Jul 10 11:46:51 qwiff /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Jul 10 11:46:51 qwiff /kernel: sio1: type 16550A Jul 10 11:46:51 qwiff /kernel: lpt0 at 0x3bc-0x3c3 irq 7 on isa Jul 10 11:46:51 qwiff /kernel: lpt0: Interrupt-driven port Jul 10 11:46:51 qwiff /kernel: lp0: TCP/IP capable interface Jul 10 11:46:51 qwiff /kernel: psm0 at 0x60-0x63 irq 12 on motherboard Jul 10 11:46:52 qwiff /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Jul 10 11:46:52 qwiff /kernel: fdc0: NEC 72065B Jul 10 11:46:52 qwiff /kernel: fd0: 1.44MB 3.5in Jul 10 11:46:52 qwiff /kernel: 2 3C5x9 board(s) on ISA found at 0x310 0x300 Jul 10 11:46:52 qwiff /kernel: ep0 at 0x300-0x30f irq 10 on isa Jul 10 11:46:52 qwiff /kernel: ep0: aui/bnc[*BNC*] address 00:60:8c:60:ac:0e irq 10 Jul 10 11:46:53 qwiff /kernel: ep1 at 0x310-0x31f irq 11 on isa Jul 10 11:46:53 qwiff /kernel: ep1: aui/bnc[*BNC*] address 00:20:af:0f:6c:0a irq 11 Jul 10 11:46:53 qwiff /kernel: npx0 on motherboard Jul 10 11:46:53 qwiff /kernel: npx0: INT 16 interface Jul 10 11:46:53 qwiff /kernel: Probing for devices on the PCI bus: Jul 10 11:46:53 qwiff /kernel: ahc0 rev 0 int a irq 5 on pci0:12 Jul 10 11:46:53 qwiff /kernel: ahc0: aic7870 Ultra Single Channel, SCSI Id=7, aic7870, 255 SCBs Jul 10 11:46:53 qwiff /kernel: ahc0 waiting for scsi devices to settle Jul 10 11:46:53 qwiff /kernel: (ahc0:0:0): "FUJITSU M1606S-512 6234" type 0 fixed SCSI 2 Jul 10 11:46:54 qwiff /kernel: sd0(ahc0:0:0): Direct-Access 1041MB (2131992 512 byte sectors) Jul 10 11:46:54 qwiff /kernel: (ahc0:1:0): "MATSHITA CD-ROM CR-5XX 1.0b" type 5 removable SCSI 1 Jul 10 11:46:54 qwiff /kernel: cd0(ahc0:1:0): CD-ROM Jul 10 11:46:54 qwiff /kernel: cd0(ahc0:1:0): NOT READY asc:a0,0 Jul 10 11:46:54 qwiff /kernel: can't get the size Jul 10 11:46:54 qwiff /kernel: Jul 10 11:46:55 qwiff /kernel: (ahc0:2:0): "TANDBERG TDC 4100 J04:" type 1 removable SCSI 2 Jul 10 11:46:55 qwiff /kernel: st0(ahc0:2:0): Sequential-Access density code 0x0, drive empty Jul 10 11:46:55 qwiff /kernel: pci0:16: OPTI, device=0xc822, class=bridge (host) [no driver assigned] Jul 10 11:46:49 qwiff named[64]: starting. named LOCAL-951116.090057 Thu Nov 16 09:00:57 1995 jkh@westhill.cdrom.com:/usr/src/usr.sbin/named Jul 10 11:46:50 qwiff named[65]: Ready to answer queries. Jul 10 11:46:52 qwiff lpd[87]: restarted Jul 10 11:47:07 qwiff login: login on ttyv0 as jbh Jul 10 11:48:02 qwiff su: jbh to root on /dev/ttyv0 Jul 10 11:48:12 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 10 11:48:12 qwiff /kernel: st0: Cannot set selected mode Jul 10 11:48:12 qwiff /kernel: st0: oops not queued Jul 10 11:49:58 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 10 11:49:58 qwiff /kernel: st0: Cannot set selected mode Jul 10 11:50:24 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 10 11:50:24 qwiff /kernel: st0: Cannot set selected mode Jul 10 11:51:35 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 10 11:51:35 qwiff /kernel: st0: Cannot set selected mode Jul 10 11:55:00 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 10 11:55:00 qwiff /kernel: st0: Cannot set selected mode Jul 10 11:55:00 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 10 11:55:00 qwiff /kernel: st0: Cannot set selected mode The following is output from an: mt -f /dev/rst0 status Present Mode: Density = ECMA TC17 Blocksize variable ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = 0x00 Blocksize variable Mode 2: Density = 0x00 Blocksize variable Mode 3: Density = 0x00 Blocksize variable I hope that I am not reporting a non-existent bug, but I have tried all suggestion and still have not managed to get the tape drive to work. I was also unable to get the drive to work with FreeBSD 2.0.5 using an Adaptec 1542CF on a previous 386 installation. Thank you helping. I am happy to do any testing etc that my be required to fix the problem. John Hartley Graphica Software Pty. Ltd. jbh@labyrinth.net.au North Fitzroy, Victoria Australia. From owner-freebsd-bugs Tue Jul 9 20:23:39 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA01726 for bugs-outgoing; Tue, 9 Jul 1996 20:23:39 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA01719 for ; Tue, 9 Jul 1996 20:23:33 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA20926; Wed, 10 Jul 1996 13:16:45 +1000 Date: Wed, 10 Jul 1996 13:16:45 +1000 From: Bruce Evans Message-Id: <199607100316.NAA20926@godzilla.zeta.org.au> To: bde@zeta.org.au, mrm@MARMOT.Mole.ORG, zach@blizzard.gaffaneys.com Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> attributes. I now think it should refuse to the move if it can't >> preserve all the attributes. It can simply unlink the target and >> avoid unlinking the source if there is a problem. >Or, one could leave it as it is, and accept the known, rather predictable, >and simple behavior instead of a more complicated and unknown behavior. To predict the behaviour, you need to know if the move is across file systems and the current bugs in mv. Only mv's within a file system are predictable. Another bug in mv: touch /tmp/z chflags uchg /tmp/z mv /tmp/z /tmp/z1 # Fails as expected mv /tmp/z ~ # Copies the file to ~/z, then fails to # unlink ~/z, leaving two copies of the # file, one without the uchg flag. If mv happens to use `cp -pRP' (which it does for everything except regular files) then the result is similar. cp knows about file flags and sets the uchg flag in the copy, except of course if the target file system doesn't support the uchg file flag. Bruce From owner-freebsd-bugs Tue Jul 9 22:38:30 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09994 for bugs-outgoing; Tue, 9 Jul 1996 22:38:30 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA09909 for ; Tue, 9 Jul 1996 22:38:14 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id FAA03547; Wed, 10 Jul 1996 05:38:13 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma003544; Wed Jul 10 05:38:10 1996 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id WAA29432; Tue, 9 Jul 1996 22:38:09 -0700 Date: Tue, 9 Jul 1996 22:38:09 -0700 From: "M.R.Murphy" Message-Id: <199607100538.WAA29432@meerkat.mole.org> To: bde@zeta.org.au Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> attributes. I now think it should refuse to the move if it can't > >> preserve all the attributes. It can simply unlink the target and > >> avoid unlinking the source if there is a problem. > > >Or, one could leave it as it is, and accept the known, rather predictable, > >and simple behavior instead of a more complicated and unknown behavior. What I wrote sure sounds harsh. I didn't mean for it to be. My wife says I'm a churlish lout. > > To predict the behaviour, you need to know if the move is across file > systems and the current bugs in mv. Only mv's within a file system > are predictable. Yes. This is painful. > > Another bug in mv: > > touch /tmp/z > chflags uchg /tmp/z > mv /tmp/z /tmp/z1 # Fails as expected > mv /tmp/z ~ # Copies the file to ~/z, then fails to > # unlink ~/z, leaving two copies of the > # file, one without the uchg flag. > > If mv happens to use `cp -pRP' (which it does for everything except regular > files) then the result is similar. cp knows about file flags and sets the > uchg flag in the copy, except of course if the target file system doesn't > support the uchg file flag. > I have a suggestion that I'd like to have shot down. Or amplified. It's heretical in that it doesn't follow tradition. Suppose the following: 1) a directory, say /tmp owned by bin, group bin, writable. 2) a user, say mrm, uid=101(mrm) gid=200(home) groups=200(home), 0(wheel). Then file creation, cp, mv, chmod, chgrp might well behave as 1) cd /tmp; :>xyz would result in xyz owned by mrm, group home, rather than owned by mrm, group bin, that is, not like present *BSD behavior. Like System V, group and owner of newly created file is determined by uid, gid of creator, not by containing directory. 2) user mrm can chgrp /tmp/xyz to group home or wheel. 3) user mrm can then mv or cp /tmp/xyz to somewhere else legal, i.e., writable directory, with attributes maintained if legal, so that, for example, a mv of an sgid file leaves it sgid iff the group is one to which the user belongs. mv and cp leave group alone if it's one to which the mover or copier belongs. 4) chgrp leaves other attributes as-is if the chgrp is legal. This means that, for user mrm as above, % cd /tmp; :>xyz; chmod 2775 xyz; chgrp wheel xyz; mv xyz ~ ends up with xyz owned by mrm, group wheel, and sgid in mrm's home directory. Not the sequence of errors that now occurs. 5) a file in a writable directory belonging to another user and moved or copied by mrm would end up belonging to mrm, no matter whether the destination was on the same or a different file system. The group would remain the same if it was a group to which mrm belonged, and would change to the gid of mrm if not. Does this make workgroups of users reasonable? I think so. Users user1, user2, and user3 could all belong to group projectA, even if they were of different gid and effectively work on projectA if they chgrp as required. I don't think it requires the System V newgrp, either, a program I was never too fond of. I haven't been too fond of the BSD behavior of sticking group in a directory, either. It's tolerable, but not too desirable, I think. NO giving away a file through chown. root can do anything. Does this make sense? I hope so. Is this poorly stated? Yes. Should it be moved from bugs? Almost certainly. Is it so untraditional that it could never be? Probably. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good. From owner-freebsd-bugs Wed Jul 10 00:40:11 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18469 for bugs-outgoing; Wed, 10 Jul 1996 00:40:11 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA18321 for ; Wed, 10 Jul 1996 00:40:00 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA30946; Wed, 10 Jul 1996 17:36:01 +1000 Date: Wed, 10 Jul 1996 17:36:01 +1000 From: Bruce Evans Message-Id: <199607100736.RAA30946@godzilla.zeta.org.au> To: bde@zeta.org.au, mrm@MARMOT.Mole.ORG Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I have a suggestion that I'd like to have shot down. Or amplified. It's >heretical in that it doesn't follow tradition. Suppose the following: > 1) a directory, say /tmp owned by bin, group bin, writable. > 2) a user, say mrm, uid=101(mrm) gid=200(home) groups=200(home), 0(wheel). Aha! The point is that so files shouldn't default to having group bin except in the misconfigured case when the user is in group bin. Users normally can't write to directories that they don't have group access to, but there is a problem for world-writable (probably sticky) directories. I propose to not use BSD gid semantics if the resulting gid couldn't be set by the user directly. >Then file creation, cp, mv, chmod, chgrp might well behave as > 1) cd /tmp; :>xyz would result in xyz owned by mrm, group home, > rather than owned by mrm, group bin, that is, not like present > *BSD behavior. Like System V, group and owner of newly created > file is determined by uid, gid of creator, not by containing directory. I think this is too large a change. > 2) user mrm can chgrp /tmp/xyz to group home or wheel. Works already. > 3) user mrm can then mv or cp /tmp/xyz to somewhere else legal, i.e., > writable directory, with attributes maintained if legal, so that, > for example, a mv of an sgid file leaves it sgid iff the group is > one to which the user belongs. mv and cp leave group alone if > it's one to which the mover or copier belongs. Works already except when the user doesn't have permission to change the source gid. > 4) chgrp leaves other attributes as-is if the chgrp is legal. This means > that, for user mrm as above, > % cd /tmp; :>xyz; chmod 2775 xyz; chgrp wheel xyz; mv xyz ~ > ends up with xyz owned by mrm, group wheel, and sgid in mrm's > home directory. Not the sequence of errors that now occurs. No, the chmod is an error because you're not in group bin. Reversing the chmod and the chgrp works now, and the above sequence works if the initial gid is reasonable. > 5) a file in a writable directory belonging to another user and > moved or copied by mrm would end up belonging to mrm, no matter > whether the destination was on the same or a different file system. > The group would remain the same if it was a group to which mrm > belonged, and would change to the gid of mrm if not. This would make mv too different from rename() and it is too late to change rename(). >Does this make workgroups of users reasonable? I think so. Users user1, >user2, and user3 could all belong to group projectA, even if they >were of different gid and effectively work on projectA if they >chgrp as required. I don't think it requires the System V newgrp, either, I think there is a problem with stuff created in /tmp and mv'ed to a project directory. Now it has gid bin in /tmp and the project directory's gid when it is mv'ed. The chgrp to bin has to fail for the correct gid to be preserved. (BTW, patch screws up gids iff it is run by root because the chgrp _doesn't_ fail for root. It creates temporary files in /tmp and then mv's them to the final (patched) file. It actually uses an internal version of mv.) If files created in /tmp have your real gid, then mv would have to be careful not to preserve it when mv'ing to a project dir, since the real gid is not always suitable for projects. Bruce From owner-freebsd-bugs Wed Jul 10 00:48:55 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18829 for bugs-outgoing; Wed, 10 Jul 1996 00:48:55 -0700 (PDT) Received: from beatrix.fss.fokker.nl (beatrix.fss.fokker.nl [145.73.136.30]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA18822 for ; Wed, 10 Jul 1996 00:48:53 -0700 (PDT) Received: from jitterix.fss.fokker.nl by beatrix.fss.fokker.nl with SMTP id AA24528 (5.67b/IDA-1.5 for ); Wed, 10 Jul 1996 09:49:24 +0200 Received: by jitterix.fss.fokker.nl (940816.SGI.8.6.9//ident-1.0) id JAA20106; Wed, 10 Jul 1996 09:46:17 +0200 Date: Wed, 10 Jul 1996 09:46:17 +0200 Message-Id: <199607100746.JAA20106@jitterix.fss.fokker.nl> From: Jan-Hein Buhrman To: fbugs@jraynard.demon.co.uk Cc: freebsd-bugs@freefall.freebsd.org In-Reply-To: <199607092340.QAA18238@freefall.freebsd.org> (fbugs@jraynard.demon.co.uk) Subject: Re: docs/1378: sgmlfmt generated freebsd-faq.tex does not LaTeX Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>>> "James" == James Raynard writes: >>>>>> "David E. O'Brien" writes: >> [...] >> Enter >> [ the kernel goes into configuration mode ] >> Disable Interesting. There's an lsqb-rsqb combination right at the start of > the FAQ which it seems to have accepted... > Anyway, I'll be committing a version of the FAQ tonight which will fix > this. Thanks for the report. My guess it's because LaTeX sees a `\\[VSPACE]' command, even when the optional parameter is on the next line. Perhaps SGMLs should be translated to something more smart in general, like `\\{}' (or `\\\mbox{}', whatever, but a real {La,}TeX guru probably can come up with a nice solution). -- Jan-Hein Buhrman -- Fokker Space B.V. ------- -- ---------------------- +31 71 52.45472 ------------------------------------ From owner-freebsd-bugs Wed Jul 10 01:00:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA19294 for bugs-outgoing; Wed, 10 Jul 1996 01:00:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA19283; Wed, 10 Jul 1996 01:00:02 -0700 (PDT) Date: Wed, 10 Jul 1996 01:00:02 -0700 (PDT) Message-Id: <199607100800.BAA19283@freefall.freebsd.org> To: freebsd-bugs Cc: From: J Wunsch Subject: Re: gnu/1379: Man command problem, when it writes into symlinked dir Reply-To: J Wunsch Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR gnu/1379; it has been noted by GNATS. From: J Wunsch To: max@sfc.wide.ad.jp Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: gnu/1379: Man command problem, when it writes into symlinked dir Date: Wed, 10 Jul 1996 09:37:39 +0200 (MET DST) As Masafumi NAKANE wrote: > The man command doesn't check the owner of the symbolic link when it > writes the formatted man page out to symlinked cat? directory. The man command itself does not need to check anything (except for deciding whether it should present the message ``Formatting man page.'') As long as the target directory permissions are sufficient for it to write something there (i.e., for the setuid man command, the target directory is writable by user `man'), it can write the cat page, otherwise it simply can't do it. It's not running setuid root, and it never did. Btw., symlinks don't have an owner or other attributes. What you see as their owner is the ownership and permission of their parent directory, but it's entirely meaningless as long as the *target* of the symlink is concerned. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Jul 10 06:44:17 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA12145 for bugs-outgoing; Wed, 10 Jul 1996 06:44:17 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA12132 for ; Wed, 10 Jul 1996 06:44:12 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id NAA05977; Wed, 10 Jul 1996 13:44:10 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma005974; Wed Jul 10 13:44:03 1996 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id GAA00726; Wed, 10 Jul 1996 06:44:02 -0700 Date: Wed, 10 Jul 1996 06:44:02 -0700 From: "M.R.Murphy" Message-Id: <199607101344.GAA00726@meerkat.mole.org> To: bde@zeta.org.au, mrm@mole.Mole.ORG Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >I have a suggestion that I'd like to have shot down. Or amplified. It's > >heretical in that it doesn't follow tradition. Suppose the following: > > > 1) a directory, say /tmp owned by bin, group bin, writable. > > 2) a user, say mrm, uid=101(mrm) gid=200(home) groups=200(home), 0(wheel). > > Aha! The point is that so files shouldn't default to having group bin > except in the misconfigured case when the user is in group bin. Users > normally can't write to directories that they don't have group access > to, but there is a problem for world-writable (probably sticky) > directories. I propose to not use BSD gid semantics if the resulting > gid couldn't be set by the user directly. I think that the world-writable directory imposing group is the real problem here (as you say below). What's reasonable to do about it? > > >Then file creation, cp, mv, chmod, chgrp might well behave as > > > 1) cd /tmp; :>xyz would result in xyz owned by mrm, group home, > > rather than owned by mrm, group bin, that is, not like present > > *BSD behavior. Like System V, group and owner of newly created > > file is determined by uid, gid of creator, not by containing directory. > > I think this is too large a change. Me too. Too big a change, even though it's equivalently simple compared to the *BSD behavior. That is, creator determines group vs. directory determines group. Would it be too big a change for creator determines group if the directory is world writable? I think that'd fix the problem that we (maybe not we, maybe just me?) now see with /tmp. Is that the equivalent of what you meant by "not use BSD gid semantics if the resulting gid couldn't be set by the user directly"? No, I think it isn't. If the user were in group bin and the directory was group bin, then the group of the created file would be bin. Otherwise, it would be the user's group. I'd prefer for it to just be the user's group if the directory is world writable. Bad? [...] > > >Does this make workgroups of users reasonable? I think so. Users user1, > >user2, and user3 could all belong to group projectA, even if they > >were of different gid and effectively work on projectA if they > >chgrp as required. I don't think it requires the System V newgrp, either, > > I think there is a problem with stuff created in /tmp and mv'ed to a > project directory. Now it has gid bin in /tmp and the project > directory's gid when it is mv'ed. The chgrp to bin has to fail for the > correct gid to be preserved. (BTW, patch screws up gids iff it is run > by root because the chgrp _doesn't_ fail for root. It creates temporary > files in /tmp and then mv's them to the final (patched) file. It > actually uses an internal version of mv.) If files created in /tmp have > your real gid, then mv would have to be careful not to preserve it when > mv'ing to a project dir, since the real gid is not always suitable for > projects. If files created in /tmp have your real gid and you move the file to the project dir and the real gid is not suitable for the project, then you ought to change the group of the file to the project group either before or after moving it to the project dir, no? That you can move the file to the project dir means that you can do the chgrp, right? -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-bugs Wed Jul 10 07:51:23 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA15711 for bugs-outgoing; Wed, 10 Jul 1996 07:51:23 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA15703 for ; Wed, 10 Jul 1996 07:51:20 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0ue0bI-0004fbC; Wed, 10 Jul 96 09:50 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id JAA23359; Wed, 10 Jul 1996 09:50:13 -0500 Message-Id: <199607101450.JAA23359@sunc210.tellabs.com> Subject: 2.1-960627-SNAP == 2.1.5 Beta ? (fwd) To: jkh@time.cdrom.com Date: Wed, 10 Jul 1996 09:50:13 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is the third time I'm sending this e-mail because I never received the courtesy of a reply. I'm concerned that I can do a generic FTP install and get a mish-mash of system libraries which causes major problems. Given that a 2.1.5R release is imminent, doesn't anyone else think this is a problem? I didn't think 2.1-960627-SNAP was "on the 2.2 track"... toybox> uname -a FreeBSD toybox.hq.tellabs.com 2.1-960627-SNAP FreeBSD 2.1-960627-SNAP #0: Fri Jun 28 09:40:31 1996 jkh@whisker.cdrom.com:/usr/src/sys/compile/GENERIC i386 toybox> ls -l libc* -r--r--r-- 1 bin bin 497710 Jun 28 03:44 libc.a -r--r--r-- 1 bin bin 403106 Jul 3 1994 libc.so.1.1 -r--r--r-- 1 bin bin 466907 Jan 25 1995 libc.so.2.0 -r--r--r-- 1 bin bin 435248 Apr 27 16:57 libc.so.2.2 Jordan - You wrote: > > Jordan, if you want me to run anything against my system before I > > blow it away (in case you were curious as to how the installation > > gave me a bogus libc.so) just ask, but soon. ;v) > > Not necessary - you're on the 2.2 track and I'm not really dealing > with problems there until 2.1.5 is out the door, so don't wait on me > here.. :-) > Ummm.... I'm confused. I thought 2.1-960627-SNAP *was* 2.1.5 Beta 1. I thought I was doing a 2.1.5 Beta 1 install. Didn't I? - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA -------------------------------------------------------------------------- From owner-freebsd-bugs Wed Jul 10 08:15:29 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18196 for bugs-outgoing; Wed, 10 Jul 1996 08:15:29 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA18188 for ; Wed, 10 Jul 1996 08:15:27 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA15173; Wed, 10 Jul 1996 11:15:05 -0400 Date: Wed, 10 Jul 1996 11:15:05 -0400 From: Garrett Wollman Message-Id: <9607101515.AA15173@halloran-eldar.lcs.mit.edu> To: "M.R.Murphy" Cc: bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1375: Extraneous warning from mv(1) In-Reply-To: <199607100538.WAA29432@meerkat.mole.org> References: <199607100538.WAA29432@meerkat.mole.org> Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > 1) cd /tmp; :>xyz would result in xyz owned by mrm, group home, > rather than owned by mrm, group bin, that is, not like present > *BSD behavior. Like System V, group and owner of newly created > file is determined by uid, gid of creator, not by containing directory. I think I have a better proposal, which is essentially the same as Bruce's: 1) If the gid of the directory is in cr_groups[], then use it. 2) Otherwise, use cr_groups[0]. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Wed Jul 10 08:26:58 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18935 for bugs-outgoing; Wed, 10 Jul 1996 08:26:58 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA18927 for ; Wed, 10 Jul 1996 08:26:50 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id PAA06498; Wed, 10 Jul 1996 15:26:39 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma006494; Wed Jul 10 15:26:29 1996 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id IAA01005; Wed, 10 Jul 1996 08:26:29 -0700 Date: Wed, 10 Jul 1996 08:26:29 -0700 From: "M.R.Murphy" Message-Id: <199607101526.IAA01005@meerkat.mole.org> To: mrm@mole.Mole.ORG, wollman@lcs.mit.edu Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 1) cd /tmp; :>xyz would result in xyz owned by mrm, group home, > > rather than owned by mrm, group bin, that is, not like present > > *BSD behavior. Like System V, group and owner of newly created > > file is determined by uid, gid of creator, not by containing directory. > > I think I have a better proposal, which is essentially the same as > Bruce's: > > 1) If the gid of the directory is in cr_groups[], then use it. > > 2) Otherwise, use cr_groups[0]. > Short and sweet. Also more "BSDish". I think it's better than what I suggested in a BSD environment, and I think it gets rid of the /tmp owned by bin problem. It still leaves the "management of a project by gid" having to remember to chgrp to the project group in the project directory on a move or copy from /tmp, but that's no big deal (I think). Suitable negative feedback for forgetting. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-bugs Wed Jul 10 08:42:26 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA20358 for bugs-outgoing; Wed, 10 Jul 1996 08:42:26 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA20344 for ; Wed, 10 Jul 1996 08:42:21 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id IAA04256; Wed, 10 Jul 1996 08:42:14 -0700 (PDT) To: mikebo@tellabs.com cc: bugs@freebsd.org Subject: Re: 2.1-960627-SNAP == 2.1.5 Beta ? (fwd) In-reply-to: Your message of "Wed, 10 Jul 1996 09:50:13 CDT." <199607101450.JAA23359@sunc210.tellabs.com> Date: Wed, 10 Jul 1996 08:42:13 -0700 Message-ID: <4254.837013333@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Huh. I and several other people replied - this was a bogus compat21 library spamming you and it's been fixed in the latest 2.1.5-GAMMA on freefall.freebsd.org. Jordan From owner-freebsd-bugs Wed Jul 10 10:37:38 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA28588 for bugs-outgoing; Wed, 10 Jul 1996 10:37:38 -0700 (PDT) Received: from mickey.umiacs.umd.edu (mickey.umiacs.umd.edu [128.8.120.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA28568 for ; Wed, 10 Jul 1996 10:37:27 -0700 (PDT) Received: (smpatel@localhost) by mickey.umiacs.umd.edu (8.7.5/UMIACS-0.9/04-05-88) id NAA31959; Wed, 10 Jul 1996 13:35:00 -0400 (EDT) Date: Wed, 10 Jul 1996 13:34:59 -0400 (EDT) From: Sujal Patel To: freebsd-bugs@freebsd.org Subject: out of mbuf clusters Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After you run out of mbuf clusters, the entires system beings swapping very hard (until rebooted). I know this would normally panic the system (and it's nice that it doesn't), but is there a memory leak in the handler for this situation? Sujal From owner-freebsd-bugs Wed Jul 10 11:13:20 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA01507 for bugs-outgoing; Wed, 10 Jul 1996 11:13:20 -0700 (PDT) Received: (from jhay@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA01487; Wed, 10 Jul 1996 11:13:17 -0700 (PDT) Date: Wed, 10 Jul 1996 11:13:17 -0700 (PDT) From: John Hay Message-Id: <199607101813.LAA01487@freefall.freebsd.org> To: hsu@clinet.fi, jhay, freebsd-bugs Subject: Re: kern/1066 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Arnet driver: panic when ifconfig PPP -> HDLC State-Changed-From-To: open-closed State-Changed-By: jhay State-Changed-When: Wed Jul 10 11:10:36 PDT 1996 State-Changed-Why: Last problems were fixed with revision 1.8 of if_ar.c. From owner-freebsd-bugs Wed Jul 10 13:32:38 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10921 for bugs-outgoing; Wed, 10 Jul 1996 13:32:38 -0700 (PDT) Received: from guarany.cpd.unb.br (guarany.cpd.unb.br [164.41.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA10892 for ; Wed, 10 Jul 1996 13:32:19 -0700 (PDT) Received: from antares.linf.unb.br by guarany.cpd.unb.br (AIX 3.2/UCB 5.64/4.03) id AA61614; Wed, 10 Jul 1996 17:28:48 -0300 Received: from centaurus by antares.linf.unb.br (4.1/SMI-4.1) id AA09773; Wed, 10 Jul 96 17:33:55 WST From: e8917523@antares.linf.unb.br (Daniel C. Sobral) Message-Id: <9607102133.AA09773@antares.linf.unb.br> Subject: Re: 2.1-960627-SNAP: YP problem To: freebsd-bugs@freebsd.org Date: Wed, 10 Jul 1996 17:33:55 -0400 (WST) In-Reply-To: <199607090443.XAA21244@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 8, 96 11:43:55 pm Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk mikebo@tellabs.com writes: > > > I still can't figure out how the test program seemed to work before > > though. > > > Yes, it still works... I don't get it. But hey, if I got a bogus libc.so Mmmm... The libc.a was o.k. Maybe it used libc.a instead of libc.so... -- Daniel C. Sobral (8-DCS) e8917523@linf.unb.br * Psychiatric Hospital? And everyone there is an FBI agent? * From owner-freebsd-bugs Wed Jul 10 13:41:41 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11700 for bugs-outgoing; Wed, 10 Jul 1996 13:41:41 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA11694 for ; Wed, 10 Jul 1996 13:41:36 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA25744; Thu, 11 Jul 1996 06:40:03 +1000 Date: Thu, 11 Jul 1996 06:40:03 +1000 From: Bruce Evans Message-Id: <199607102040.GAA25744@godzilla.zeta.org.au> To: freebsd-bugs@freefall.freebsd.org, j@uriah.heep.sax.de Subject: Re: gnu/1379: Man command problem, when it writes into symlinked dir Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As Masafumi NAKANE wrote: > > > The man command doesn't check the owner of the symbolic link when it > > writes the formatted man page out to symlinked cat? directory. > > The man command itself does not need to check anything (except for > deciding whether it should present the message ``Formatting man > page.'') Yes it does. It's setuid man and needs to check for security holes such as the one given in detail in the PR. It assumes that writing in the system cat directories is OK because the source file must be in a system man directory, but the PR shows how to have the source in a user directory. > otherwise it simply can't do it. It's not running setuid root, and it > never did. It runs as setuid man, and usually did, except last month in -current, when setuid'ness was turned off. > Btw., symlinks don't have an owner or other attributes. What you see > as their owner is the ownership and permission of their parent > directory, but it's entirely meaningless as long as the *target* of > the symlink is concerned. Yes, the cause of problem is different from the one reported. `man' probably needs to switch to the user's id unless both the source and the target directories are in trusted places. This may involve eliminating symlinks. Bruce From owner-freebsd-bugs Wed Jul 10 18:33:22 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA04160 for bugs-outgoing; Wed, 10 Jul 1996 18:33:22 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA04152 for ; Wed, 10 Jul 1996 18:33:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id SAA05738; Wed, 10 Jul 1996 18:33:07 -0700 (PDT) Message-Id: <199607110133.SAA05738@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Sujal Patel cc: freebsd-bugs@freebsd.org Subject: Re: out of mbuf clusters In-reply-to: Your message of "Wed, 10 Jul 1996 13:34:59 EDT." From: David Greenman Reply-To: davidg@root.com Date: Wed, 10 Jul 1996 18:33:06 -0700 Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >After you run out of mbuf clusters, the entires system beings swapping >very hard (until rebooted). I know this would normally panic the system >(and it's nice that it doesn't), but is there a memory leak in the >handler for this situation? Mbuf clusters are never freed back to the global free memory pool. If your machine doesn't have much memory and the number of clusters that get allocated is large, then there won't be much left for user processes and the machine will thrash or worse. You have to have the memory resources if you want to handle high networking loads. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Wed Jul 10 18:40:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA04672 for bugs-outgoing; Wed, 10 Jul 1996 18:40:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA04654; Wed, 10 Jul 1996 18:40:02 -0700 (PDT) Date: Wed, 10 Jul 1996 18:40:02 -0700 (PDT) Message-Id: <199607110140.SAA04654@freefall.freebsd.org> To: freebsd-bugs Cc: From: Mike Pritchard Subject: Re: misc/1380: Year 2000 breakage with tm_year Reply-To: Mike Pritchard Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR misc/1380; it has been noted by GNATS. From: Mike Pritchard To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: misc/1380: Year 2000 breakage with tm_year Date: Wed, 10 Jul 1996 18:35:45 -0700 (PDT) Stephen J. Roznowski wrote: > >Description: > > Several programs have a hardcoded 19 in responses for the year. > This will break in 4 years... > [...] > --- 1467,1474 ---- > struct tm *gmtime(); > t = gmtime(&stbuf.st_mtime); > reply(213, > ! "%04d%02d%02d%02d%02d%02d", > ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, Isn't there a TM_YEAR_BASE symbol defined somewhere that should be used instead of a hardcoded 1900? -- Mike Pritchard mpp@FreeBSD.org "Go that way. Really fast. If something gets in your way, turn" From owner-freebsd-bugs Wed Jul 10 19:00:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA05772 for bugs-outgoing; Wed, 10 Jul 1996 19:00:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA05744; Wed, 10 Jul 1996 19:00:01 -0700 (PDT) Date: Wed, 10 Jul 1996 19:00:01 -0700 (PDT) Message-Id: <199607110200.TAA05744@freefall.freebsd.org> To: freebsd-bugs Cc: From: "Stephen J. Roznowski" Subject: Re: misc/1380: Year 2000 breakage with tm_year Reply-To: "Stephen J. Roznowski" Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR misc/1380; it has been noted by GNATS. From: "Stephen J. Roznowski" To: mpp@freefall.freebsd.org Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: misc/1380: Year 2000 breakage with tm_year Date: Wed, 10 Jul 1996 21:50:52 -0400 > From: Mike Pritchard > Subject: Re: misc/1380: Year 2000 breakage with tm_year > > Stephen J. Roznowski wrote: > > >Description: > > > > Several programs have a hardcoded 19 in responses for the year. > > This will break in 4 years... > > [...] > > --- 1467,1474 ---- > > struct tm *gmtime(); > > t = gmtime(&stbuf.st_mtime); > > reply(213, > > ! "%04d%02d%02d%02d%02d%02d", > > ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, > > Isn't there a TM_YEAR_BASE symbol defined somewhere that should > be used instead of a hardcoded 1900? When I submitted my original changes to NetBSD, I used that symbol; however, according to "J.T. Conklin " the definition of the tm_year field is "years since 1900" according to Standard C. [and not years since TM_YEAR_BASE] -SR From owner-freebsd-bugs Wed Jul 10 21:38:46 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA13791 for bugs-outgoing; Wed, 10 Jul 1996 21:38:46 -0700 (PDT) Received: from freebsd.gaffaneys.com ([134.129.252.26]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA13786 for ; Wed, 10 Jul 1996 21:38:41 -0700 (PDT) Received: (from zach@localhost) by freebsd.gaffaneys.com (8.7.5/8.7.3) id XAA02619; Wed, 10 Jul 1996 23:38:50 -0500 (CDT) To: Garrett Wollman Cc: "M.R.Murphy" , bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1375: Extraneous warning from mv(1) References: <199607100538.WAA29432@meerkat.mole.org> <9607101515.AA15173@halloran-eldar.lcs.mit.edu> From: Zach Heilig Date: 10 Jul 1996 23:38:48 -0500 In-Reply-To: Garrett Wollman's message of Wed, 10 Jul 1996 11:15:05 -0400 Message-ID: <87raqjjtev.fsf@freebsd.gaffaneys.com> Lines: 113 X-Mailer: Gnus v5.2.32/Emacs 19.31 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman writes: > I think I have a better proposal, which is essentially the same as > Bruce's: > 1) If the gid of the directory is in cr_groups[], then use it. > 2) Otherwise, use cr_groups[0]. This is more or less what I was trying to say in my very first message, but perhaps I flubbed it up :-). I think the current behavior should be an option, perhaps by requiring the setgid bit to be on the parent directory. I don't see an obvious need for this, except perhaps for mail spool directories. It would not be required for workgroups, since (presumably) everyone working on files in the project directory are also in the correct group, so the right thing would happen anyway. There are still some issues having to do with what mv(1) and related utilities do with the group read, write, and execute/search bit; the setuid bit; and the setgid bit. The other read, write, and execute/search bits don't matter as much, since they don't try to restrict who can access the file (and if they were on, there is really no reason to turn them off). We need to come up with a consistant (and BSD-like) behavior for what exactly should be done when some combination of those bits are set. The current mv(1) handles the case of setuid/setgid bits very badly. I read the man page for what cp(1) is supposed to do regarding permissions (I didn't verify that works as advertised), and I don't think its behavior as documented covers all the bases very well when applied to mv(1). mv(1) really really wants to preserve the precise mode and ownership flags, but cp(1) merely gives it a good effort, if you tell it to. But since it is simply copying, cp(1) doesn't complain if preserving the flags is impossible. These issues are also valid for archival programs like tar, cpio, pax, etc.. since they are always "moving" files across "filesystems". First, regarding the filesystem flags, I think we all can agree that some of the flags should be preserved when moving across filesystems. The question is which ones? Obviously uchg and schg files need to be left completely alone, but what about the dump flag? I'm not completely sure what that means (the man page helpfully says that if the nodump flag is set, the file should never be dumped. Dumped meaning never discarded, or never copied, prevent the use of dd(1), or ??). Next, about the file-mode mask. When should the other read, write, execute/search; group read, write, execute/search; setgid; and setuid bits be ok to preserve, and when should some or all of them be dropped? This will probably have to depend on the umask setting when deciding if to keep the write, read or execute bits when either the owner, gid, or both have to change. Consider these situations: 1) There is a file with the mode '-rwxrwsr-x', and you need to move it to a public bin directory on a different filesystem. You do not own the file, but one of your gids is the same as the file's gid. You have write permissions to the directory you are moving to (perhaps the bits are 'drwxrwxr-x'). After mv(1) finishes, what permissions should the file have? I say the bits should be '-rwxrwsr-x' with you as the new owner, but the file still has the original gid. 2) The original file has the mode bits '-rwsrwsr-x'. Obviously, if you are not the owner, the setuid and probably the setgid bit should be dropped. Should mv(1) print out a message saying it dropped them? I think so. Should the move succeed at all? The answer is debatable, but I'm beginning to think it should not, even if you could simulate the move with appropriate calls to rm(1), cp(1), chmod(1), and chgrp(1). 3) You own a file with mode '-rwsr-x---', but for some reason, none of your gids match the file's gid (you might have been kicked out of that group, or it is from an archive made on a different system). You would no longer want logins with a gid that matches the files gid to be able to execute that file (since it is setuid), but you want to continue using it yourself. You move the file into your personal bin directory. Since none of your gids match the file's gid, the file's new gid changes to the gid on your bin directory (whew!). This would give a different group execute permissions for that file if the mode bits stayed the same. This is probably not acceptable, so should the permissions after the move be '-rwxr-x---', or '-rws------'? I don't know, but the bits should not be '-rwsr-x---'. 4) Same situation as #3, but the original file's permissions are '-rwsr-xr-x'. In this case, I think the permissions should be unchanged after the move (You would not be giving a different set of people access). There are many more examples that should be looked into to make sure the archive and file utilities do the right thing in preserving the various bits and ownerships. The operations should be atomic, in case the file contains sensitive information that only certain people should have access to. By that, I mean files should be created with the correct permissions and ownerships already attached before the copy starts. If the gid cannot be preserved, and none of the 'other' bits are on, the group bits should be forced off as well. This means that mv(1) and the various archive programs should check to see if the gid (and perhaps the uid) can be preserved before creating the file, and calculate the proper mode bits to pass to open(2), creat(2), or mkdir(2). This way, the file would always have the access bits set properly, and there would be no race condition where "unauthorized" people could access the file. I have much more to say on this subject, but I would like some feedback first ;-) -- Zach Heilig (zach@blizzard.gaffaneys.com) Support bacteria -- it's the only culture some people have! ALL unsolicited commercial email is unwelcome. My policy is avoid dealing with companies that send out such mailings. From owner-freebsd-bugs Wed Jul 10 22:42:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA18146 for bugs-outgoing; Wed, 10 Jul 1996 22:42:04 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA18125 for ; Wed, 10 Jul 1996 22:41:58 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id PAA13520; Thu, 11 Jul 1996 15:38:49 +1000 Date: Thu, 11 Jul 1996 15:38:49 +1000 From: Bruce Evans Message-Id: <199607110538.PAA13520@godzilla.zeta.org.au> To: freebsd-bugs@freefall.freebsd.org, sjr@zombie.ncsc.mil Subject: Re: misc/1380: Year 2000 breakage with tm_year Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Isn't there a TM_YEAR_BASE symbol defined somewhere that should > > be used instead of a hardcoded 1900? > > When I submitted my original changes to NetBSD, I used that symbol; > however, according to "J.T. Conklin " the definition > of the tm_year field is "years since 1900" according to Standard C. > [and not years since TM_YEAR_BASE] Right. TM_YEAR_BASE is private to the FreeBSD (Olsen) implementation of Standard C time stuff. It is defined in the private header tzfile.h. An old version of tzfile.h was erroneously turned into a standard header and used in various utilities in 4.4Lite, but it was removed in FreeBSD a year or so ago. Bruce From owner-freebsd-bugs Thu Jul 11 00:54:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA23508 for bugs-outgoing; Thu, 11 Jul 1996 00:54:04 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA23495 for ; Thu, 11 Jul 1996 00:53:51 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA09318; Thu, 11 Jul 1996 09:51:54 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA11931; Thu, 11 Jul 1996 09:51:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA14194; Thu, 11 Jul 1996 09:13:01 +0200 (MET DST) From: J Wunsch Message-Id: <199607110713.JAA14194@uriah.heep.sax.de> Subject: Re: misc/1380: Year 2000 breakage with tm_year To: sjr@zombie.ncsc.mil Date: Thu, 11 Jul 1996 09:13:01 +0200 (MET DST) Cc: freebsd-bugs@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607110200.TAA05744@freefall.freebsd.org> from "Stephen J. Roznowski" at "Jul 10, 96 07:00:01 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Stephen J. Roznowski wrote: > > > reply(213, > > > ! "%04d%02d%02d%02d%02d%02d", > > > ! 1900+t->tm_year, t->tm_mon+1, t->tm_mday, > > > > Isn't there a TM_YEAR_BASE symbol defined somewhere that should > > be used instead of a hardcoded 1900? > > When I submitted my original changes to NetBSD, I used that symbol; > however, according to "J.T. Conklin " the definition > of the tm_year field is "years since 1900" according to Standard C. > [and not years since TM_YEAR_BASE] This is right (and points out the sillyness of the standard -- year 2012 will be encoded as 112 then). Anyway, TM_YEAR_BASE is what our library uses when computing this field, so it's safe to also use it for the reverse calculation. In effect, the ANSI C standard mandates that TM_YEAR_BASE will always remain at 1900. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Thu Jul 11 01:08:44 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA24377 for bugs-outgoing; Thu, 11 Jul 1996 01:08:44 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA24369 for ; Thu, 11 Jul 1996 01:08:29 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA19123; Thu, 11 Jul 1996 18:03:28 +1000 Date: Thu, 11 Jul 1996 18:03:28 +1000 From: Bruce Evans Message-Id: <199607110803.SAA19123@godzilla.zeta.org.au> To: wollman@lcs.mit.edu, zach@blizzard.gaffaneys.com Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org, mrm@MARMOT.Mole.ORG Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I read the man page for what cp(1) is supposed to do regarding >permissions (I didn't verify that works as advertised), and I don't >think its behavior as documented covers all the bases very well when >applied to mv(1). mv(1) really really wants to preserve the precise >mode and ownership flags, but cp(1) merely gives it a good effort, if >you tell it to. But since it is simply copying, cp(1) doesn't >complain if preserving the flags is impossible. These issues are also Right. >valid for archival programs like tar, cpio, pax, etc.. since they are >always "moving" files across "filesystems". Note that none of these supports file flags, even for pass-through mode in cpio and pax. >First, regarding the filesystem flags, I think we all can agree that >some of the flags should be preserved when moving across filesystems. >The question is which ones? Obviously uchg and schg files need to be >left completely alone, but what about the dump flag? I'm not uchg and schg should prevent moving (they prevent unlinking) and nodump should be preserved. >completely sure what that means (the man page helpfully says that if >the nodump flag is set, the file should never be dumped. Dumped It means that you don't want the file backed up much. This is explained OK in dump(8). install(1) preserves all flags except the nodump flag. uappnd and sappnd should be handled like uchg and schg. `arch' is the only flag whose handling isn't obvious. Perhaps it should be cleared by moving to a different file system so that the file gets archived in its new place. It isn't honoured by any archivers except msdosfs ones. >Next, about the file-mode mask. When should the other read, write, >execute/search; group read, write, execute/search; setgid; and setuid >bits be ok to preserve, and when should some or all of them be >dropped? This will probably have to depend on the umask setting when >deciding if to keep the write, read or execute bits when either the >owner, gid, or both have to change. Consider these situations: Bits should never be dropped, except possibly the set*id bits. mv should not set the set*id bits before copying the whole file. Perhaps it should create the target file with a mode of 0600 and set the bits last. The fastmove() case of mv currently creates the target with the mode of the source. cp is more careful. >1) There is a file with the mode '-rwxrwsr-x', and you need to move it >to a public bin directory on a different filesystem. You do not own >the file, but one of your gids is the same as the file's gid. You >have write permissions to the directory you are moving to (perhaps the >bits are 'drwxrwxr-x'). After mv(1) finishes, what permissions should >the file have? I say the bits should be '-rwxrwsr-x' with you as the >new owner, but the file still has the original gid. This seems reasonable, but I would prefer this case to fail. >2) The original file has the mode bits '-rwsrwsr-x'. Obviously, if >you are not the owner, the setuid and probably the setgid bit should >be dropped. Should mv(1) print out a message saying it dropped them? >I think so. Should the move succeed at all? The answer is debatable, >but I'm beginning to think it should not, even if you could simulate >the move with appropriate calls to rm(1), cp(1), chmod(1), and >chgrp(1). Now I'm even more convinced that all cases where a mode would change should fail :-). This is for mv. Archivers should behave more like cp. Does cp actually do the wrong thing in any cases? What should cp -p do with the mode if it can't preserve the ids? Bruce From owner-freebsd-bugs Thu Jul 11 08:00:23 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA17116 for bugs-outgoing; Thu, 11 Jul 1996 08:00:23 -0700 (PDT) Received: from jagor.srce.hr (root@jagor.srce.hr [161.53.2.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA16073; Thu, 11 Jul 1996 07:56:40 -0700 (PDT) Received: from a8-p2-zg.tel.hr [205.219.255.145] by jagor.srce.hr (8.7.5/8.6.12.CI) id QAA06595; Thu, 11 Jul 1996 16:56:09 +0200 (MET DST) Message-ID: <31E51772.188D@jagor.srce.hr> Date: Thu, 11 Jul 1996 17:02:10 +0200 From: Sinisa Sehovic X-Mailer: Mozilla 3.0b3 (Win95; I) MIME-Version: 1.0 To: announce@freebsd.org CC: hackers@freebsd.org, questions@freebsd.org, bugs@freebsd.org, current@freebsd.org, security@freebsd.org, ports@freebsd.org Subject: unsubscribe Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-bugs Thu Jul 11 16:18:29 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA13383 for bugs-outgoing; Thu, 11 Jul 1996 16:18:29 -0700 (PDT) Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA13369 for ; Thu, 11 Jul 1996 16:18:23 -0700 (PDT) Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id bd01621; 12 Jul 96 0:17 +0100 Received: from jraynard.demon.co.uk ([158.152.42.77]) by relay-3.mail.demon.net id aa16659; 11 Jul 96 23:29 +0100 Received: (from fbugs@localhost) by jraynard.demon.co.uk (8.6.12/8.6.12) id RAA01997; Thu, 11 Jul 1996 17:19:51 GMT Date: Thu, 11 Jul 1996 17:19:51 GMT Message-Id: <199607111719.RAA01997@jraynard.demon.co.uk> From: James Raynard To: bde@zeta.org.au CC: zach@blizzard.gaffaneys.com, freebsd-bugs@freefall.freebsd.org In-reply-to: <199607110803.SAA19123@godzilla.zeta.org.au> (message from Bruce Evans on Thu, 11 Jul 1996 18:03:28 +1000) Subject: Re: bin/1375: Extraneous warning from mv(1) Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>>> Bruce Evans writes: > > Now I'm even more convinced that all cases where a mode would change > should fail :-). This is for mv. Me too :-) > Archivers should behave more like cp. > Does cp actually do the wrong thing in any cases? What should cp -p > do with the mode if it can't preserve the ids? Does POSIX.2 say anything relevant to this discussion? -- James Raynard, Edinburgh, Scotland james@jraynard.demon.co.uk http://www.freebsd.org/~jraynard/ From owner-freebsd-bugs Thu Jul 11 22:25:43 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA01605 for bugs-outgoing; Thu, 11 Jul 1996 22:25:43 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA01579 for ; Thu, 11 Jul 1996 22:25:10 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id HAA09329; Fri, 12 Jul 1996 07:22:55 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA25409; Fri, 12 Jul 1996 07:22:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id GAA18579; Fri, 12 Jul 1996 06:54:25 +0200 (MET DST) From: J Wunsch Message-Id: <199607120454.GAA18579@uriah.heep.sax.de> Subject: Re: bin/1375: Extraneous warning from mv(1) To: fbugs@jraynard.demon.co.uk (James Raynard) Date: Fri, 12 Jul 1996 06:54:25 +0200 (MET DST) Cc: bde@zeta.org.au, zach@blizzard.gaffaneys.com, freebsd-bugs@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607111719.RAA01997@jraynard.demon.co.uk> from James Raynard at "Jul 11, 96 05:19:51 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As James Raynard wrote: > > Archivers should behave more like cp. > > Does cp actually do the wrong thing in any cases? What should cp -p > > do with the mode if it can't preserve the ids? > > Does POSIX.2 say anything relevant to this discussion? cp -p: If the user ID or the group ID cannot be duplicated, the file permission bits S_ISUID and S_ISGID shall be cleared. If these bits are present in the source file but are not duplicated in the destination file, it is unspecified whether cp writes a diagnostic message to standard error. mv (across file systems, if necessary): (5) The file hierarchy rooted in source_file shall be duplicated as a file hierarchy rooted in the destination path. The following characteristics of each file in the file hierarchy shall be duplicated: (a) The time of last data modification and time of last access. (b) The user ID and group ID. (c) The file mode. If the user ID, group ID, or file mode of a regular file cannot be duplicated, the file mode bits S_ISUID and S_ISGID shall not be duplicated. [...] If the duplication of the file hierarchy fails for any reason, mv shall write a diagnostic message to standard error, do nothing more with the current source_file, and go on to any remaining source_files. If the duplication of the file characteristics fails for any reason, mv shall write a diagnostic message to standard error, but this failure shall not cause mv to modify its exit status. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Fri Jul 12 00:34:57 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA10581 for bugs-outgoing; Fri, 12 Jul 1996 00:34:57 -0700 (PDT) Received: from nico.aarnet.edu.au (nico.aarnet.edu.au [139.130.204.16]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA10574 for ; Fri, 12 Jul 1996 00:34:55 -0700 (PDT) Received: from nico.telstra.net (nico.aarnet.edu.au [139.130.204.16]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA03176 for ; Fri, 12 Jul 1996 17:32:04 +1000 Date: Fri, 12 Jul 1996 17:32:04 +1000 (EST) From: Wayne Farmer To: bugs@freebsd.org Subject: Unable to Upgrade from 2.1.0-R to 2.1.5-G using boot floppy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When booting from the 2.1.5-G boot floppy and selecting the upgrade option, everythng seems fine until it heads off to the partition editor. It reports unable to run partition editor and that's it. This is on a pretty clean 2.1.0-R system. Hardware is Pentium-133, 32 Mb, 500Mb IDE drive and 2Gb Seagate SCSI. root partition is on IDE and the rest is on the SCSI disk. Wayne From owner-freebsd-bugs Fri Jul 12 00:52:54 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA11532 for bugs-outgoing; Fri, 12 Jul 1996 00:52:54 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA11522 for ; Fri, 12 Jul 1996 00:52:46 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id AAA02013; Fri, 12 Jul 1996 00:52:12 -0700 (PDT) To: Wayne Farmer cc: bugs@freebsd.org Subject: Re: Unable to Upgrade from 2.1.0-R to 2.1.5-G using boot floppy In-reply-to: Your message of "Fri, 12 Jul 1996 17:32:04 +1000." Date: Fri, 12 Jul 1996 00:52:12 -0700 Message-ID: <2010.837157932@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk !! Uh, I'll look into this right now - thanks! Jordan > When booting from the 2.1.5-G boot floppy and selecting the upgrade > option, everythng seems fine until it heads off to the partition editor. > > It reports unable to run partition editor and that's it. This is on a > pretty clean 2.1.0-R system. > > Hardware is Pentium-133, 32 Mb, 500Mb IDE drive and 2Gb Seagate SCSI. > > root partition is on IDE and the rest is on the SCSI disk. > > Wayne From owner-freebsd-bugs Fri Jul 12 09:10:44 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA22280 for bugs-outgoing; Fri, 12 Jul 1996 09:10:44 -0700 (PDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA22273 for ; Fri, 12 Jul 1996 09:10:40 -0700 (PDT) Received: from uucp2.UU.NET by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.UU.NET [192.48.96.33]) id QQaybg07444; Fri, 12 Jul 1996 12:10:30 -0400 (EDT) Received: from tricotek.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 12 Jul 1996 12:10:31 -0400 Received: from tricotek. by (SMI-8.6/Trico-HEH-05-Mar) id JAA14561; Fri, 12 Jul 1996 09:21:11 -0400 Received: by tricotek. (SMI-8.6/SMI-SVR4) id JAA14558; Fri, 12 Jul 1996 09:21:10 -0400 Date: Fri, 12 Jul 1996 09:21:10 -0400 From: tricotek!henry@uunet.uu.net (Henry Hojnacki) Message-Id: <199607121321.JAA14558@tricotek.> To: uunet!FreeBSD.org!bugs@uunet.uu.net Subject: Installation Problems (2.0.5 + 2.1) Cc: tricotek!henry@uunet.uu.net X-Sun-Charset: US-ASCII Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello! I have sent this message to questions@FreeBSD.com, but have not received a response in more than a week, so I am trying the bugs address. Please forgive me if I am being too impatient. Having used the 2.0 version for several months now, I decided to upgrade to the 2.0.5 version. During the installation procedure, I experience a lock up in the menu screen. Here is my hardware setup, followed by a detailed description of the problem: 100 MHz Pentium Intel TRITON chip set M/B On board IDE controller (No IDE Hard Drive, floppy only) NCR53C810 SCSI HBA 1GB SCSI Hard Drive 32MB memory Diamiond Stealth 65 Video 17" Monitor SoundBlaster16 Firstly, I have successfully intalled 2.0, and am currently using this with X11R6 from XFree86. No major problems here. I created the boot floppy for 2.0.5 from the Walnut Creek CDROM. When I attempt to boot from it, it goes thru the normal boot procedure, but when the install menu should come up, nothing happens. I have toggled to the debug screen via Alt-F2, and see no surprinsing messages. When I toggle back via Alt-F1, the install menu miracuously appears, however it does not respond to any key strokes. If I toggle to the debug screen and back again, the screen appears updated. I borrowed a 2.1 release CD from a friend, and wrote a new boot floppy. Same problem happens. I have swapped out cards one by one and in all combinations. The only time I was able to get a normally responding install menu is if I removed the NCR SCSI card. The install menu worked just fine. Of course, not having a SCSI card means no hard drive in my case, so the install procedure is somewhat moot. I then tried an Adaptec 2940 SCSI card. Things got worse. The install menu never appeared at all! Even after toggling to the debug screen and back did nothing. It appears that the boot procedure did complete successfully. I have verified the integrity of the boot floppy by trying it on another machine. The major difference of this machine was that an IDE drive was present, and no SCSI devices were attached. Can this be some factor caused by the on board IDE controller? Has anyone seen this before? Will I ever be able to upgrade from 2.0? Any advice suggestion, help etc would be much appreciated. Thank You in Advance, |-|-| Henry Hojnacki Trico Technology Center 24467 West Ten Mile Rd Southfield MI 48034 810 354 5010 ext 317(voice) 810 354 5019 (fax) From owner-freebsd-bugs Fri Jul 12 10:10:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27053 for bugs-outgoing; Fri, 12 Jul 1996 10:10:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27044; Fri, 12 Jul 1996 10:10:01 -0700 (PDT) Resent-Date: Fri, 12 Jul 1996 10:10:01 -0700 (PDT) Resent-Message-Id: <199607121710.KAA27044@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, roberto@keltia.freenix.fr Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA26737 for ; Fri, 12 Jul 1996 10:05:55 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id TAA03363 for ; Fri, 12 Jul 1996 19:05:49 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id TAA08609 for FreeBSD-gnats-submit@freebsd.org; Fri, 12 Jul 1996 19:05:08 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Alpha.5/keltia-uucp-2.8) id TAA18867; Fri, 12 Jul 1996 19:04:20 +0200 (MET DST) Message-Id: <199607121704.TAA18867@keltia.freenix.fr> Date: Fri, 12 Jul 1996 19:04:20 +0200 (MET DST) From: Ollivier Robert Reply-To: roberto@keltia.freenix.fr To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/1381: /bin/csh doesn't handle SIGWINCH correctly Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1381 >Category: bin >Synopsis: When one resizes an xterm window, $TERMCAP doesn't change >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 12 10:10:01 PDT 1996 >Last-Modified: >Originator: Ollivier Robert >Organization: Usenet Canal Historique >Release: FreeBSD 2.2-CURRENT i386 >Environment: FreeBSD keltia.freenix.fr 2.2-CURRENT FreeBSD 2.2-CURRENT #14: Thu Jul 11 22:38:57 MET DST 1996 roberto@keltia.freenix.fr:/src/src/sys/compile/DKELTIA i386 -r-xr-xr-x 1 bin bin 266240 Jul 12 01:49 /bin/csh* CURRENT from 1996 07/11 14:00:01, ctm#2220 from cvs-cur. >Description: /bin/csh as shipped in 2.2-CURRENT (and probably 2.1-STABLE and the forthcoming 2.1.5-RELEASE) doesn't support or is bug in its SIGWINCH handling. Windows size changes are not shown in the environment, resulting in problems with many programs. The bug is present in 2.2-CURRENT (as shown) and in 2.1-RELEASE (as shown to me by a friend of mine). >How-To-Repeat: Here is an xterm, 80x24 wide and the shell used is /bin/csh. TERMCAP=xterm|vs100|xterm terminal emulator (X window system):li#24:hs:ts=\E[?E\E[?%i%dT:fs=\E[?F:es:ds=\E[?E:is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:rs=\E>\E[?1;3;4;5l\E[?7;8h:@7=\E[4~:kh=\E[1~:kI=\E[2~:k0=\E[10~:kD=\E[3~:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:kP=\E[5~:kN=\E[6~:K1=\EOw:K2=\EOy:K3=\EOu:K4=\EOq:K5=\EOs:al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:LE=\E[%dD:ct=\E[3g:st=\EH:co#80:le=^H:bs:am:if=/usr/share/tabset/vt100:ac=llmmkkjjuuttvvwwqqxxnnpprr``aa:ks=\E[?1h\E=:ke=\E[?1l\E>:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=\177:ho=\E[H:pt:vt#3:xn:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut: Note li#24 and co#80. Resize the window to something else. I choose to change it to 50x42. After doing it, the environment is TERMCAP=xterm|vs100|xterm terminal emulator (X window system):li#24:hs:ts=\E[?E\E[?%i%dT:fs=\E[?F:es:ds=\E[?E:is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:rs=\E>\E[?1;3;4;5l\E[?7;8h:@7=\E[4~:kh=\E[1~:kI=\E[2~:k0=\E[10~:kD=\E[3~:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:kP=\E[5~:kN=\E[6~:K1=\EOw:K2=\EOy:K3=\EOu:K4=\EOq:K5=\EOs:al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:LE=\E[%dD:ct=\E[3g:st=\EH:co#80:le=^H:bs:am:if=/usr/share/tabset/vt100:ac=llmmkkjjuuttvvwwqqxxnnpprr``aa:ks=\E[?1h\E=:ke=\E[?1l\E>:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=\177:ho=\E[H:pt:vt#3:xn:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut: Note that neither li# nor co# has changed. >Fix: Unknown, maybe borrow code from tcsh which handle this rightly. This is probably the reason why many people will never see the bug, not being foolish enough to use pure csh :-) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Jul 12 11:01:50 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA01312 for bugs-outgoing; Fri, 12 Jul 1996 11:01:50 -0700 (PDT) Received: from queue.IEOR.Berkeley.EDU (queue.IEOR.Berkeley.EDU [128.32.142.108]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA01300 for ; Fri, 12 Jul 1996 11:01:44 -0700 (PDT) Received: from cander.dnai.com (isdn8-232.isdn.dnai.com) by queue.IEOR.Berkeley.EDU (4.1/1.28) id AA22826; Fri, 12 Jul 96 11:04:42 PDT Date: Fri, 12 Jul 96 11:04:42 PDT Message-Id: <9607121804.AA22826@queue.IEOR.Berkeley.EDU> X-Sender: cander@queue.berkeley.edu X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bugs@freebsd.org From: Charles Anderson Subject: Bug with header files? Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The following combination blows up in ctype.h due to a lack of a typedef for rune_t: #define _POSIX_SOURCE #include #include I'm running 2.1R, but I haven't gotten the networking going yet so I didn't use send-pr (sorry). I'm not in tune with the zen of _POSIX_SOURCE or the _BSD_TYPE macros (e.g. BSD_WCHAR is what rune_t should be), so I can't suggest a fix. Charles. From owner-freebsd-bugs Sat Jul 13 02:07:51 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA24961 for bugs-outgoing; Sat, 13 Jul 1996 02:07:51 -0700 (PDT) Received: (from joerg@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA24940; Sat, 13 Jul 1996 02:07:48 -0700 (PDT) Date: Sat, 13 Jul 1996 02:07:48 -0700 (PDT) From: Joerg Wunsch Message-Id: <199607130907.CAA24940@freefall.freebsd.org> To: roberto@keltia.freenix.fr, joerg, freebsd-bugs Subject: Re: bin/1381 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: When one resizes an xterm window, $TERMCAP doesn't change State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Sat Jul 13 11:06:22 MET DST 1996 State-Changed-Why: This is a no-bug. The shell is not supposed to modify its environment. The intended way for programs to learn about this is the strct winsize. The entire winsize idea is a bit weird though. From owner-freebsd-bugs Sat Jul 13 02:08:13 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25041 for bugs-outgoing; Sat, 13 Jul 1996 02:08:13 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA25026 for ; Sat, 13 Jul 1996 02:08:06 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA25974; Sat, 13 Jul 1996 11:08:03 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA10210; Sat, 13 Jul 1996 11:08:02 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA22511; Sat, 13 Jul 1996 09:26:36 +0200 (MET DST) From: J Wunsch Message-Id: <199607130726.JAA22511@uriah.heep.sax.de> Subject: Re: Bug with header files? To: cander@queue.IEOR.Berkeley.EDU (Charles Anderson) Date: Sat, 13 Jul 1996 09:26:36 +0200 (MET DST) Cc: bugs@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9607121804.AA22826@queue.IEOR.Berkeley.EDU> from Charles Anderson at "Jul 12, 96 11:04:42 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Charles Anderson wrote: > The following combination blows up in ctype.h due to a lack of a typedef for > rune_t: > > #define _POSIX_SOURCE > #include > #include > > I'm running 2.1R, but I haven't gotten the networking going yet so I didn't > use send-pr (sorry). It's too late to send-pr it anyway. :) The bug is not present in -current. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Sat Jul 13 02:09:58 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25151 for bugs-outgoing; Sat, 13 Jul 1996 02:09:58 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA25130 for ; Sat, 13 Jul 1996 02:09:54 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA26015; Sat, 13 Jul 1996 11:09:52 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA10244; Sat, 13 Jul 1996 11:09:51 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA22793; Sat, 13 Jul 1996 09:49:39 +0200 (MET DST) From: J Wunsch Message-Id: <199607130749.JAA22793@uriah.heep.sax.de> Subject: Re: Installation Problems (2.0.5 + 2.1) To: tricotek!henry@uunet.uu.net (Henry Hojnacki) Date: Sat, 13 Jul 1996 09:49:39 +0200 (MET DST) Cc: freebsd-bugs@FreeBSD.org (FreeBSD bugs list) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607121321.JAA14558@tricotek.> from Henry Hojnacki at "Jul 12, 96 09:21:10 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Henry Hojnacki wrote: (Please, limit your line length to ~ 70 characters. Your message is what i consider ``close to be unreadable''.) > Can this be some factor caused by the on board IDE controller? Has > anyone seen this before? Will I ever be able to upgrade from 2.0? > Any advice suggestion, help etc would be much appreciated. The IDE adapter is unlikely the culprit. Remember, all recent mainboards ship with one on-board, but you are the only one reporting this kind of problems. The error description looks mysterious. I cannot really imagine of any bug that would cause _this_ behaviour. Are you sure all your interrupt assignments are okay? The PCI code has been drastically changed over the time, perhaps our PCI gurus might have an idea. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Sat Jul 13 02:10:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25232 for bugs-outgoing; Sat, 13 Jul 1996 02:10:06 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25203; Sat, 13 Jul 1996 02:10:04 -0700 (PDT) Date: Sat, 13 Jul 1996 02:10:04 -0700 (PDT) Message-Id: <199607130910.CAA25203@freefall.freebsd.org> To: freebsd-bugs Cc: From: J Wunsch Subject: Re: bin/1381: /bin/csh doesn't handle SIGWINCH correctly Reply-To: J Wunsch Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/1381; it has been noted by GNATS. From: J Wunsch To: roberto@keltia.freenix.fr Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: bin/1381: /bin/csh doesn't handle SIGWINCH correctly Date: Sat, 13 Jul 1996 09:24:11 +0200 (MET DST) As Ollivier Robert wrote: > /bin/csh as shipped in 2.2-CURRENT (and probably 2.1-STABLE and the > forthcoming 2.1.5-RELEASE) doesn't support or is bug in its SIGWINCH > handling. Windows size changes are not shown in the environment, resulting > in problems with many programs. This is a non-bug. Shells are not supposed to intercept SIGWINCH for the purpose of fiddling with incorrect TERMCAP values. (Heck, the TERMCAP entry in the environment is even a rather useless invention.) li# and co# in the TERMCAP are a design error for terminals that can handle more than one size (i.e., for everything more recent than a VT100 or ADM3A). The correct way for programs to handle this is to examine the struct winsize, which is correctly updated, at least for cases like xterm or vty's. Of course, struct winsize is a design error. :-) It doesn't get notified when you turn your VT220 into 132-column mode manually. The entire tty capabilities' handling is a design error. :-)) Read the ``UNIX haters handbook'' for a more detailed explanation. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Sat Jul 13 04:30:16 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05358 for bugs-outgoing; Sat, 13 Jul 1996 04:30:16 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05348 for freebsd-bugs; Sat, 13 Jul 1996 04:30:14 -0700 (PDT) Date: Sat, 13 Jul 1996 04:30:14 -0700 (PDT) From: GNU GNATS Message-Id: <199607131130.EAA05348@freefall.freebsd.org> To: freebsd-bugs Subject: Summary of Problem Reports Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Number of currently open reports: 313 Number of curently analyzed reports: 20 From owner-freebsd-bugs Sat Jul 13 04:30:18 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05369 for bugs-outgoing; Sat, 13 Jul 1996 04:30:18 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA05342 for freebsd-bugs; Sat, 13 Jul 1996 04:30:14 -0700 (PDT) Date: Sat, 13 Jul 1996 04:30:14 -0700 (PDT) From: GNU GNATS Message-Id: <199607131130.EAA05342@freefall.freebsd.org> To: freebsd-bugs Subject: List of open Problem Reports Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is the list of currently open problem reports [1994/11/30] kern/34 nullfs and union mounts can result in wild pointer r [1995/01/10] bin/104 pax -rwl may corrupt filesystem [1995/01/14] bin/115 systat iostat display doesn't scale high enough [1995/01/14] bin/129 fsck cannot take a mount point as an argument [1995/01/15] bin/146 version of compress is kinda old and slow [1995/01/21] bin/173 rc trys to mount modload fs before ld is available. [1995/01/21] bin/174 Poor error message from stty [1995/01/22] kern/176 EIDRM not defined in errno.h [1995/01/24] gnu/183 can't resolve "operator <<" overload [1995/01/24] bin/184 send-pr says "Aborting ..." and happily removes the [1995/01/30] bin/198 1.1.5.1 pine binary loops; top shows fancy values [1995/03/02] misc/229 acos() core dump [1995/03/28] kern/281 Messages printed when checking CD ROM device too ver [1995/03/28] kern/282 buslogic adapter information WAY too verbose [1995/04/01] kern/291 PCI devices still probe/attach after being disabled [1995/04/20] kern/353 xcdplayer crashes machine (with NCR810 SCSI) [1995/04/20] misc/355 policy on /usr/local permission in base release [1995/05/08] bin/389 Simultaneous creation/deletion of dirs corrupts file [1995/05/12] bin/398 VI doesnt do the correct thing [1995/05/13] bin/401 Add REMOTE_* variables [1995/05/14] kern/405 The gpio driver does not work with the AT-GPIB, only [1995/05/15] misc/423 Sound devices are too insecure [1995/05/16] kern/425 arp entries not getting removed when interface chang [1995/05/23] i386/440 want vidcontrol option to apply settings to all sysc [1995/05/26] kern/446 unable to diskless-boot a PC when the server mounts [1995/06/14] bin/514 Crash recovery impossible without static mt/chflags. [1995/06/15] bin/517 Bad group change with 'install' [1995/06/15] bin/519 execution of quotacheck from /etc/rc fails [1995/06/17] kern/528 slow 386 reports excessive interrupt-level buffer ov [1995/06/26] kern/565 slip freezes machine [1995/07/02] kern/579 sio: RS_IBUFSIZE at 256 bytes serial lines loose dat [1995/07/04] kern/587 if_le hangs on OACTIVE with 2k buffer [1995/07/04] kern/588 Configuration of DEC ethernet cards not possible [1995/07/05] bin/591 SPAP request REJexted in stead of NAKed [1995/07/09] misc/605 NIS: get*bynis routine problems [1995/07/29] kern/638 Transmitted packets not passed to bpf in if_le.c [1995/08/01] docs/646 vmstat man page out of date [1995/08/01] bin/648 printf format conversion incorrect (duplicate) [1995/08/02] gnu/650 Current flex is outdated [1995/08/03] kern/652 Multiple addresses on one interface interacts badly [1995/08/05] gnu/655 ld -r of shared objects worked in 1.1.5, not in 2.0. [1995/08/07] bin/658 ifconfig alias has to be separately given [1995/08/07] bin/661 Hercules is not capable of having a ISO-Latin1 Scree [1995/08/11] gnu/672 Nor all ph headers get created [1995/08/11] ports/673 /bin/sh + inn1.4 innwatch going belly up [1995/08/11] bin/675 make does unnecessary rebuilds [1995/08/12] kern/677 X gets a bus error when calling mmap() [1995/08/13] bin/680 2.0.5's tip using termios doesn't act the way it did [1995/08/14] kern/688 Page fault: supervisor write, page not present [1995/08/15] i386/692 My modem is not found if my external cache is disabl [1995/08/18] kern/700 The comments in /sys/net/if.h are confusing [1995/08/21] kern/703 ppp not always deleting route properly when a ppp li [1995/08/22] bin/706 increased root DNS traffic and long latencies for r- [1995/08/29] bin/715 ls gives weird tabular form [1995/08/31] bin/716 W returns wrong results at login [1995/09/19] bin/728 /bin/sh messes up quoting when going through eval [1995/09/21] docs/731 socketpair(2) and man page inconsistent about return [1995/09/23] docs/735 missing description for mount options in fstab(5) ma [1995/09/25] gnu/737 FreeBSD-current/src/gnu/usr.bin/gzip/Makefile [1995/09/26] bin/739 Some problems when an output filter reads all input [1995/09/26] kern/742 syslog errors accessing Mac hard disks [patch] [1995/09/27] bin/743 vi cannot edit a file where the name starts with + [1995/09/27] kern/745 occasional filesystem inconsistencies, and "panic: f [1995/09/27] bin/747 date(1) gives weird time zones and interprets GMT[+- [1995/09/27] kern/750 cd9660 confused by not-ready or I/O errors FDIV030 [1995/09/28] kern/752 setting multiple addresses for a single interfaces l [1995/09/28] kern/753 my archive scsi tape drive does not work [1995/09/28] docs/754 there is no man page for the psm(4) mouse driver [1995/10/03] kern/765 umount -f can`t umount a NFS filesystem in use [1995/10/05] misc/767 Configure-time does time-warp on non-UTC CMOS - FDIV [1995/10/09] kern/774 dump fails with "slave couldn't reopen disk: Device [1995/10/11] bin/777 patch doesn't realize stdin is closed and asks quest [1995/10/12] bin/778 tar complains "EOF not on block boundary" on a good [1995/10/14] kern/781 OPEN_MAX in kernel config and FD_SETSIZE in /usr/inc [1995/10/18] bin/786 Problem with NIS and large group maps [1995/10/25] kern/792 cd9660 very slow. [1995/10/25] kern/793 ep0 cannot be configured and more. [1995/10/29] kern/798 PPP panics, touches 0xdeadc0de pointers [1995/10/29] docs/801 rlogind k, v, and x options are not documented [1995/10/31] bin/803 bsd m4 chokes and dies while FSF m4 works... [1995/11/11] bin/815 mountd reports unknown hosts with non-informative me [1995/11/12] kern/820 scsi tape problems [1995/11/13] kern/821 Config doesn't properly trap signals [1995/11/16] bin/826 tcpmux listener in inetd does not work [1995/11/20] kern/831 one minor complaint about the kernel visual config c [1995/11/22] kern/835 ed panics with SMC ultra with iomem, if no iomem in [1995/11/25] bin/839 by default, use of "at" is overly restricted [1995/11/27] bin/841 stale nfs mounts cannot be umounted [1995/11/27] kern/845 Automatic reboot says you can abort but boots anyway [1995/11/28] misc/848 Inst gripes about geometry but won't accept true val [1995/11/28] bin/850 dump treats write-protect as an EOT & spoils set FDI [1995/11/29] bin/852 Sendmail is loosing mail (apparently)! [1995/11/30] bin/854 swapinfo shows incorrect information for vnconfig'd [1995/11/30] ports/857 Need ANSI_C define to not declare some functions [1995/12/01] bin/859 /bin/sh -c does not ignore SIGINT [1995/12/02] kern/860 visual mode in kernel -c is too restrictive [1995/12/03] kern/861 sb16 support in 2.1 is erratic and has cosmetic defe [1995/12/03] kern/863 panic on kernel page fault, NULL curproc [1995/12/06] ports/869 xcdplayer installs itself is /usr/X11R6, not /usr/lo [1995/12/06] ports/871 port.subdir.mk DEBUG_FLAGS is not used for CFLAGS [1995/12/08] kern/876 NFS allows bogus accesses to cached data [1995/12/17] kern/900 ext2fs triggers divide by zero trap in vnode_pager_h [1995/12/20] i386/906 /sys/i386/boot/netboot/nb8390.com cannot recognize N [1995/12/25] bin/914 hayes dialer for tip fails 1st attempt to dial [1995/12/29] kern/920 sio output looses chars in fifo on close() [1995/12/29] kern/921 getrusage() returns 0 after system up for a long tim [1995/12/31] kern/924 EISA devices have disappeared from vmstat/systat int [1996/01/01] bin/926 Mounting nfs disks before starting mountd: Chicken o [1996/01/02] kern/927 VGA mode not restored [1996/01/03] kern/930 sio/getty problem? [1996/01/06] kern/932 de0 occasionally enables 100baseTX when plugged into [1996/01/06] misc/934 ppp dies with Bus Error when processing long LOGIN s [1996/01/09] kern/940 panic: free vnode isn't [1996/01/12] misc/942 X11 mono server dumps core on supported video hardwa [1996/01/13] ports/944 Security fixes for Fvwm 1.24r [1996/01/15] kern/946 divide-by-zero in kernel on bad disk info [1996/01/16] kern/949 panic, undebugable dump? [1996/01/17] kern/951 -current kernel crashes with devfs error on bootup [1996/01/19] kern/956 Kernel page fault, null callp [1996/01/19] bin/958 ttys file does not include all ptys [1996/01/21] bin/961 'more $file', incorrect CRLF compacting. [1996/01/23] ports/968 Netscape & cern_httpd ports out of date/dead links [1996/01/25] kern/971 Default limits for number of processes per user ridi [1996/01/25] conf/972 inetd.conf should comment out k-services if no Kerbe [1996/01/28] kern/975 getrusage returns negative deltas [1996/01/28] kern/976 NCR SCSI driver gives assertion errors and disk beco [1996/01/29] kern/978 Three deadlocks in row [1996/02/01] bin/986 problems make-ing with cd in the rule [1996/02/03] kern/991 pcvt keyboard doesn't accept input at crash reboot [1996/02/03] bin/993 g++ complains about /usr/include/machine/cpufunc.h [1996/02/06] kern/998 badness in file system silently crashes machine [1996/02/07] bin/999 /usr/share/mk/sys.mk missing common $(RM) macro [1996/02/07] kern/1001 M_NAMEI malloc leak in the kernel [1996/02/08] kern/1008 Daily crash while writing network backups to local t [1996/02/09] kern/1012 vnode_pager_putpages: attempt to write meta-data!!! [1996/02/10] kern/1016 panic: vm_page_free: freeing free page, sddump: no s [1996/02/10] kern/1017 ssh stopped working between 15th Jan and 9th Feb [1996/02/12] kern/1018 panic: unwire: page not in pmap [1996/02/12] bin/1019 getty cannot detect ppp logins [1996/02/12] kern/1020 Boca 16-port board still hangs [1996/02/12] bin/1021 pppd doesn't handle PAP-only authentication well [1996/02/12] docs/1023 using touch to create swap file for NFS doesn't work [1996/02/14] kern/1026 deadlocks if parent vfork and child has cntrl termin [1996/02/14] bin/1028 shutdown -r does not seem to always complete [1996/02/15] bin/1029 cd behaves erraticly if cwd is a mount-point, which [1996/02/17] bin/1030 /bin/sh does not pass environment variables on prope [1996/02/18] kern/1034 Instant panic in -current [1996/02/19] bin/1035 ls to terminal always uses ? for non-printable chars [1996/02/19] docs/1036 List of dead xrefs in man pages [1996/02/19] bin/1037 2.x telnetd handles CTRL-M differently than other tt [1996/02/23] bin/1040 with certain flags, route can reboot your machine. [1996/02/25] i386/1042 Warning from sio driver reports wrong device FDIV045 [1996/02/26] misc/1043 vm_bounce_alloc error on 2.1 install with 4G drive [1996/02/27] kern/1045 Lockup: b_to_q to a clist with no reserved cblocks [1996/02/27] gnu/1047 send-pr: Aborting... [1996/02/28] i386/1048 ep driver fails to detect card when told specific va [1996/02/28] bin/1050 Process (zip) hangs (unkillable) after floppy error [1996/02/29] kern/1051 zip fails on dos partition [1996/02/29] bin/1052 /bin/sh problem with new GCC (snapshot for 2.8) [1996/03/02] bin/1056 pppd fails if -detach [1996/03/05] kern/1064 Recursive panic? [1996/03/06] kern/1065 wt could crash reading short blocks [1996/03/08] bin/1068 man ignores -P option when combined with -k [1996/03/08] ports/1069 TkMan acts erroneusly on apropos [1996/03/09] bin/1070 /usr/bin/fstat doesn't display open, active pure tex [1996/03/09] ports/1072 tex port (ftplib.pl) does not support passive mode f [1996/03/09] bin/1073 telnet -8 does not work with SunOS or Solaris [1996/03/09] bin/1074 tty rows & columns settings sometimes reset to zero [1996/03/11] conf/1076 'make install' fails for /usr/src/share/examples in [1996/03/15] misc/1079 Can not work about get{host|net]byaddr on NIS. [1996/03/16] kern/1080 Panic @ _get_pt_entry+0x8 [1996/03/16] kern/1081 Fatal double fault [1996/03/17] kern/1087 Device close entry is not called when unmounting UFS [1996/03/18] docs/1089 stat manpage unclear about st_mtime & friends [1996/03/20] kern/1090 iostat displays incorrect sps count [1996/03/20] bin/1093 route's diagnostic is weird [1996/03/21] bin/1095 make's continuation line handling buggy when used wi [1996/03/23] kern/1098 File system corruption (2 cases) [1996/03/26] kern/1102 Differentiation of FreeBSD & Linux ELF binaries [pat [1996/03/28] bin/1105 Bug in find command [1996/03/28] ports/1109 mods to vim-3.0 port [1996/03/30] bin/1111 mail.local will happily deliver mail to a quota'd fi [1996/03/31] misc/1112 Can not work getnetbyaddr on NIS [1996/04/05] kern/1118 panic: setrunqueue encountered when wine fork()'s [1996/04/06] kern/1119 Mounted EXT2FS partition is not cleanly unmounted up [1996/04/06] kern/1121 System crashes on boot up just after the "devfs read [1996/04/07] kern/1122 Kernel (current) does not see all memory [1996/04/09] bin/1127 sh(1) parameter expansion for substring processing n [1996/04/11] kern/1134 PPB support is broken for multiple/unknown PPBs. [1996/04/11] kern/1135 starting an extra mountd and then killing it crashes [1996/04/12] bin/1136 broken printf in sh(1) [1996/04/14] bin/1139 uname.1 and uname.c disagree about display ordering [1996/04/14] docs/1141 pcvt(4) references non-existent man page. [1996/04/15] kern/1144 sig{add, del}set and sigismember fns don't check sig [1996/04/15] bin/1145 tftpd should support -s [1996/04/19] docs/1151 intro(3) references libc(3) and plot(3), which do no [1996/04/22] bin/1154 Configure tunN device for ip-over-ip tunnelling [1996/04/23] ports/1155 systat or top display disagreeing information [1996/04/24] kern/1157 SCSI Disk Timeouts (ahc0) [1996/04/25] bin/1158 atq uses GMT time instead of TZ time [1996/04/28] kern/1160 Panic: bad dir [1996/04/28] kern/1161 -current panic on boot if DIAGNOSTIC option is used [1996/04/29] kern/1163 2.2-960323-SNAP: fatal trap 12 [1996/04/29] kern/1164 machine locks up [1996/04/30] docs/1165 Printer Text Filter scripts should be in /usr/share/ [1996/04/30] kern/1166 pmap panic (dump available) [1996/05/02] docs/1169 bogus reference to keysu(1) in key(1) and keyinit(1) [1996/05/02] docs/1170 include files missing from get{peer,sock}name man pa [1996/05/02] kern/1171 panic: setrunnable after touching long idle windows [1996/05/07] kern/1177 Machine hangs with message "vm_fork: no pte for UPAG [1996/05/08] kern/1180 freeing held page, count=%d [1996/05/09] bin/1181 fsck displays wrong char in "option?" diagnostic [1996/05/09] bin/1182 timed records improper entry in wtmp [1996/05/09] bin/1184 ls + xterm + nvi + columns != 80 + ^Z = mangled list [1996/05/10] misc/1187 pppd dies with a segv [1996/05/11] kern/1190 panic: page fault (wild pointer?) [1996/05/13] ports/1200 pop3 requests may crash client [1996/05/13] kern/1201 FreeBSD SCSI changer driver leaves a bit to be desir [1996/05/13] bin/1202 netgroups in /etc/hosts.equiv stopped working in -st [1996/05/14] kern/1204 umount -f after SCSI reset -> reboot [1996/05/15] bin/1206 /bin/sh + emacs + ^G = ruined terminal [1996/05/16] kern/1208 Rebooting nfs server results "Permission denied" mes [1996/05/16] gnu/1209 send-pr should refuse PR's without subject and synop [1996/05/17] gnu/1210 gcc (v2.6.3) -O and -O2 compile-time bus error [1996/05/18] bin/1212 ppp eventually runs out of file descriptors [1996/05/18] kern/1213 kernel page fault [1996/05/19] kern/1216 Support for i586 clock clibration is not built in [1996/05/19] kern/1217 separating to hardrives to two IDE channels hangs th [1996/05/20] bin/1221 new gcc-2.7.2 gives a LOT of warnings, and a few ERR [1996/05/20] ports/1222 Header files conflict [1996/05/21] kern/1227 vm_page_activate: already active (new vm system) [1996/05/21] kern/1228 probe doesn't find P-n-P modem [1996/05/21] bin/1229 redundant redeclaration of `lseek' [1996/05/21] bin/1230 make ``.for'' loops iterate backwards [1996/05/21] bin/1231 make(1) execution of ``.BEGIN'' does not halt on err [1996/05/22] kern/1236 some #def's in pcvt_conf.h not braketed by #ifndef's [1996/05/23] bin/1237 [1996/05/24] bin/1241 The jot(1) command with -s (FROM 2.1.0 CD) generates [1996/05/24] bin/1242 In the "sys/stat.h" file, the S_ISFIFO and S_ISSOCK [1996/05/24] kern/1246 aic-7850 driver sees more cdroms then exists [1996/05/24] misc/1247 Conflicting header files [1996/05/24] bin/1248 /bin/sh has trouble with arguments past 9(ie. ${10}) [1996/05/25] docs/1249 incorrect manpages [1996/05/26] i386/1251 aha0 and bt0(eisa) conflicts again. [1996/05/26] kern/1252 Heavy activity on a CD causes panic [1996/05/26] kern/1256 ZNYX 314 mysterously looses packets [1996/05/26] kern/1257 System got blown away by "vm_pageout_scan: page not [1996/05/27] kern/1258 new vm code: freeing held page [1996/05/27] conf/1264 panic with two new Quantum FireBall 1280 [1996/05/27] kern/1265 warnings in pcv [1996/05/27] kern/1269 vm_pageout_scan: page not inactive? (loops, effectiv [1996/05/28] conf/1270 /etc/ttys does not list all valid ptys (breaks scree [1996/05/28] kern/1271 Kernel panic using PLIP in 27/05 current [1996/05/28] docs/1272 document the -o option for f2c [1996/05/28] bin/1273 remote hostname gets corrupted in rshd [1996/05/28] kern/1274 Kernel panics with filesystem error [1996/05/28] bin/1276 pppd hangs serial port - ENOBUFS [1996/05/29] kern/1278 SUN Solaris clients gets host not responding, when w [1996/05/30] docs/1280 locale and collating [1996/05/31] kern/1283 cleaning out some compiler fuzz from pcvt_hdr.h [1996/05/31] kern/1284 panic: vm_page_free: freeing busy page [1996/05/31] conf/1285 route_multicast and route_loopback lines in /etc/sys [1996/06/01] kern/1286 cluster_read() calls strategy routine without B_READ [1996/06/02] bin/1287 /bin/sh does alias expansion in case patterns [1996/06/02] i386/1288 wdgetctlr (wd.c) return incorrect number of cylinder [1996/06/03] bin/1289 errno breaks in thread-safe c++ compiles [1996/06/05] kern/1293 Fatal trap 12: page fault while in kernel mode (PPP/ [1996/06/06] misc/1299 National charecter problem in XFree86 [1996/06/07] kern/1301 DEC FDDI/PCI Adapter: halt code = 6 (DMA Error) [1996/06/08] kern/1302 3COM 3c590 can't receive packets [1996/06/09] bin/1305 dc miscomputes remainder [1996/06/10] kern/1307 vm_page_free: freeing busy page [1996/06/10] kern/1308 vm_page_free: wire count > 1 in 960501-SNAP [1996/06/11] kern/1311 Panic: vm_page_free while installing new kernel [1996/06/11] bin/1312 automounter hangs on boot [1996/06/12] bin/1315 ls(1) [1996/06/12] bin/1316 10 tunnel device limit [1996/06/12] ports/1318 Problem making port: squid [1996/06/12] conf/1319 muldi3 is not included into kernel's Makefile by con [1996/06/13] bin/1320 dump limits blocksize to 32K [1996/06/14] bin/1322 savecore does not take minfree into account [1996/06/14] kern/1323 960612's psm driver does not see the mouse. 960501 d [1996/06/15] kern/1326 defvs panic: cleaned vnode isn't [1996/06/16] kern/1327 keyboard probe in -current fails, X reboots machine [1996/06/18] i386/1331 changes and bug in ft driver [1996/06/18] bin/1332 changes to amd and possible nfs lkm bug? [1996/06/18] kern/1333 free vnode isn't: another -stable coredump [1996/06/19] misc/1335 /etc/security generates an error with files with spa [1996/06/19] kern/1336 Permission for .. in NFS mounts is somewhat non-intu [1996/06/20] bin/1337 Yacc skeleton parser generates warning with -Wall [1996/06/21] misc/1340 make world fails [1996/06/21] misc/1342 chgrp(1) required by MAKEDEV but not on fixit floppy [1996/06/22] kern/1345 kernel page fault, NULL pointer dereference in exit( [1996/06/25] bin/1350 sed continuation lines in text don't work [1996/06/25] bin/1351 security problem with mv(1) [1996/06/26] conf/1352 Missing files from /usr/share/info [1996/06/26] ports/1357 fvwm95-2c no longer exists -- fvwm95-2f is out [1996/07/01] bin/1361 ruptime and long downtimes [1996/07/01] docs/1362 Manual extension [1996/07/03] bin/1363 ellipses are three dots, not two. [1996/07/03] bin/1364 ps(1) bugs [1996/07/04] bin/1366 make(1) [1996/07/04] i386/1367 reprobe a device that does not exist = panic [1996/07/04] misc/1369 Need SC_MORE_LUS for Emulex MD23 also [1996/07/06] kern/1371 kernel doesn't flush all its buffers when told to ha [1996/07/06] misc/1372 compile time error with cc -ansi and RPC headers [1996/07/06] misc/1373 RPC include lacks prototypes [1996/07/06] docs/1374 the default listed in the newfs -i man page does not [1996/07/07] bin/1375 Extraneous warning from mv(1) [1996/07/07] misc/1376 if_tun.c does not set if_ibytes and if_obytes to zer [1996/07/09] bin/1377 mv(1) retains the setuid bit when it is unable to pr [1996/07/09] gnu/1379 Man command problem, when it writes into symlinked d [1996/07/09] misc/1380 Year 2000 breakage with tm_year This is the list of problem reports already analyzed: [1994/12/01] kern/35 mount -t union -o -b : lower layer not seen by shell [1995/01/11] i386/105 Distributed libm (msun) has non-standard error handl [1995/03/20] kern/260 msync and munmap don't bother to update mod times [1995/03/20] docs/264 There are no manual pages for the forms library. [1995/03/22] kern/267 NFS code gives error messages, systems jams for a fe [1995/04/09] bin/326 Weekly cron generates some usage and error messages [1995/05/09] bin/392 Simultaneous cp and ls of files on dos f/s hangs pro [1995/05/27] gnu/450 tar --exclude -c doesn't work [1995/06/17] kern/527 dump causes assertion in ncr.c [1995/06/21] docs/538 MAP_FILE not mentioned in mmap man page. [1995/10/07] bin/771 telnet character mode not set and broken when set - [1995/10/15] kern/782 chmod does a null pointer dereference [1995/10/26] kern/794 swap partition at offset 0 still broken [1995/12/04] i386/867 Notebook with APM and 3C589C in PCMCIA freezes after [1995/12/29] misc/922 From line handling incorrect in mail.local [1996/01/22] kern/965 2.0.5: system crashes daily because of "multiple fre [1996/01/30] bin/981 clnt_broadcast() is not aware of aliases [1996/03/04] kern/1059 null fs panics system [1996/03/06] kern/1067 panic: ufs_lock: recursive lock not expected, pid: 2 [1996/05/01] ports/1168 New version of pine. 3.93 fixes bugs in 3.92 and ha /* EOF -- this list has not been truncated */ From owner-freebsd-bugs Sat Jul 13 08:50:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA01055 for bugs-outgoing; Sat, 13 Jul 1996 08:50:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA01023; Sat, 13 Jul 1996 08:50:02 -0700 (PDT) Resent-Date: Sat, 13 Jul 1996 08:50:02 -0700 (PDT) Resent-Message-Id: <199607131550.IAA01023@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, kelly@fsl.noaa.gov Received: from rosemary.fsl.noaa.gov (rosemary.fsl.noaa.gov [137.75.8.41]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA29976 for ; Sat, 13 Jul 1996 08:47:01 -0700 (PDT) Received: (from kelly@localhost) by rosemary.fsl.noaa.gov (8.6.12/8.6.9) id JAA00585; Sat, 13 Jul 1996 09:46:58 -0600 Message-Id: <199607131546.JAA00585@rosemary.fsl.noaa.gov> Date: Sat, 13 Jul 1996 09:46:58 -0600 From: kelly@fsl.noaa.gov Reply-To: kelly@fsl.noaa.gov To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: conf/1382: FreeBSD's year 2000 problem (minor) Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1382 >Category: conf >Synopsis: FreeBSD has minor year 2000 problem in distr /etc/rc.local >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jul 13 08:50:01 PDT 1996 >Last-Modified: >Originator: Sean Kelly >Organization: NOAA Forecast Systems Laboratory, Boulder Colorado USA >Release: FreeBSD 2.1-STABLE i386 >Environment: Environment not relevant. >Description: The sed script in /etc/rc.local that builds the host/kernel ID line for the message of the day relies on the year not going past 1999. When the year passes 1999, the ID line is malformed. >How-To-Repeat: Wait until 2000. Reboot your system. See /etc/motd. >Fix: Change the regular expression to match four digits instead of 199 followed by any digit. Other, more reliable expressions are possible. >Audit-Trail: >Unformatted: