Re: A way to tell wich security patches are installed [Was: RELENG_4_3 calls itself -RELEASE?]
On Sat, Aug 04, 2001 at 09:58:44AM -0400, Bill Moran wrote: > Why not 4.4.1-RELEASE, 4.4.2-RELEASE, etc > It's simple, to the point. Implies upgrades. Allows you to quickly determine > exactly how current a particular system is with regards to patches, and > follows long-standing conventions. > > Just my $.02 > -Bill > Because there are two kinds of patches applied to the RELENG_4_3 branch, some kernel patches and some userland patches, there are a few problems I have seen mentioned: 1) A userland patch like telnetd does not require you to reboot, so why go through that and recompiling a kernel just to have an updated "uname -r". 2) A kernel patch requires you to reboot, so a change in the uname -r output can be seen. What I suggest is as follows: have the uname-r change after the first patch (RELEASEPLUS or anything you suggest, just have an indication that something has changed from the original -RELEASE). Keep a patch level for the kernel in the -RELEASEPLUS tag (something like RELEASEPLUS01, 02...) and have the userland patches install an empty file with a suggestive name in a standard location (probably under /var), something like /var/patches/telnetd-01, /var/patches/openssl-01, etc. These files under /var/patches could be created by the Makefiles of the respective daemons/programs/libraries, on install, if upgrading via source. Also, the upgrading via packages could probably add those files just as easily. I am not sure wether there are other methods of upgrading (I count build/installworld as a source upgrade, and this could also clean /var/patches). Since the latest upgrade of the program should leave the latest "patch evidence", it should be easy to just have a look at /var/patches and see "Oh, I missed the openssl upgrade". To avoid problems of installing older packages, the install script could clean other patch evidence regarding to that package, like "rm /var/patches/telnetd-*; touch /var/patches/telnetd-01". This way accidentally downgrading a package should also be noticed. Kernel upgrades should be reflected in uname, so those are not that complicated. It might be worth noting that this still leaves questions like "I have 4.3-RELEASEPLUS02, is my telnetd vulnerable" answered a little oddly, "Check that you have at least /var/patches/telnetd-01 or you are vulnerable". Sorry if this does not make much sense, it is 01:51am now and I need sleep. (on a side note, -FAIRINGS seems like a good idea) Have Fun! Alex +-- Alex Popa, | "Artificial Intelligence is [EMAIL PROTECTED]| no match for Natural Stupidity" +-- "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: so where did the space go?
it was vmware under linux emul. >>> lsof | grep /var >> # lsof | grep vmware | grep /var >> vmware 489 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) >> vmware 489 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) >> vmware 492 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) >> vmware 492 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) >> vmware 493 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) >> vmware 493 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > This says that a process named vmware has /var open. If you want to > free the inodes attached to the files that you have removed, kill > whatever processes may have been writing them. a! do you folk READ the message before responding? look at the first line above. the question is WHY and WHAT vmware is hanging on to. that is a physical disk. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-PRERELEASE never resume from suspend
In message <[EMAIL PROTECTED]> Hajimu UMEMOTO writes: : I just did it. When booting kernel without any pccard stuff, it works : fine, suspend/resume is okay. The output of dmesg is attached. Thanks for the demsg and the test. I was afraid that you'd say something like that :-(. I'll investigate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-PRERELEASE never resume from suspend
> On Sat, 04 Aug 2001 13:29:47 -0600 > Warner Losh <[EMAIL PROTECTED]> said: imp> I've not seen this problem. Can you do me the favor of trying to boot imp> a kernel without the pccard stuff in it at all and let me know if you imp> get similar behavior? That would eliminate at least one variable imp> that's changed much since July 21. Thank you very much and I look imp> forward to the results. I hope it makes no difference, but fear that imp> it might. I just did it. When booting kernel without any pccard stuff, it works fine, suspend/resume is okay. The output of dmesg is attached. Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-PRERELEASE #0: Fri Aug 3 14:08:10 JST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PIANO Calibrating clock(s) ... TSC clock: 22960 Hz, i8254 clock: 1193233 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium/P55C (quarter-micron) (229.59-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 100655104 (98296K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00446000 - 0x05ff5fff, 96141312 bytes (23472 pages) avail memory = 93716480 (91520K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fd820 bios32: Entry = 0xfd831 (c00fd831) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xd86c pnpbios: Found PnP BIOS data at 0xc00fdfd0 pnpbios: Entry = f:ba2e Rev = 1.0 Other BIOS signatures found: ACPI: 000fe1d0 Preloaded elf kernel "kernel" at 0xc042. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk Creating DISK md0 pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=c7011045) apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 123243776 bytes/sec bzero() bandwidth = 164527805 bytes/sec pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=c7011045) pcib0: on motherboard found-> vendor=0x1045, dev=0xc701, revid=0x32 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found-> vendor=0x1045, dev=0xc700, revid=0x31 class=06-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found-> vendor=0x102c, dev=0x00e5, revid=0xc6 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base 2000, size 24 found-> vendor=0x1045, dev=0xc861, revid=0x10 class=0c-03-10, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=10 found-> vendor=0x1045, dev=0xd568, revid=0x30 class=01-01-82, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base 1000, size 4 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: (vendor=0x102c, dev=0x00e5) at 3.0 ohci0: irq 10 at device 5.0 on pci0 ohci0: Could not map memory device_probe_and_attach: ohci0 attach returned 6 atapci0: port 0x1000-0x100f at device 20.0 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0x1000 ata0: mask=03 status0=50 status1=00 ata0: mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI probe a=00 b=00 ata0-slave: ATAPI probe a=00 b=00 ata0: mask=03 status0=50 status1=00 ata0-master: ATA probe a=01 b=a5 ata0: devices=01 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0x1008 ata1: mask=00 status0=ff status1=ff ata1: probe allocation failed ex_isa_identify() ata-: ata0 exists, using next available unit number ata-: ata1 exists, using next available unit number Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 23 devices, largest 282 bytes PNP: adding irq mask 00x4 PNP: adding io range 0x20-0x21, size=0x2, align=0x1 PNP: adding io range 0xa0-0xa1, size=0x2, align=0x1 PNP: end config pnpbios: handle 1 device ID PNP (d041) PNP0100: adding irq mask 00x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0x1 PNP0100: end config pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0x1 PNP0b00: end config pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 PNP0800: end config pnpbios: handle 4 device ID PNP0800 (
Re: RELENG_4_3 calls itself -RELEASE?
On Sat, Aug 04, 2001 at 12:35:44PM -0700, Chad R. Larson wrote: > On Sat, Aug 04, 2001 at 09:47:32AM -0400, Jonathan Chen wrote: > > 1) Have the cvs scripts add the latest commit date/time to a version.h > >everytime a commit occurs in a branch. Display/use it accordingly. > > I suggested that a couple of years ago. I thought "newvers.sh" > should get updated by any CVS commit. > > It was met with something between indifference and hostility. The > most valid (IMHO) objection is that people were regularly building > the kernel without building world (or vice versa), something that I > believe happens less often now with the new build tools. Then, > unless you had a version.h for every kernel module and perhaps even > every userland program, you still didn't know exactly what you had. This wouldn't be a problem if, say, the make process automagically adds the "version.o" (or call it whatever) object to any linked executable. version.[ch?] would of course contain something like: static const char* __foo_version __attribute__ ((unused)) "foo"; and be properly depended on to build whenever updated. This shouldn't be more than a trivial change in the global bsd .mk files. My only concern would be CVS repo bloat. Perhaps a cvs meister would care to comment on this issue? I don't suppose there is a way to tell CVS to not worry about deltas or logs, is there? Were there any other objections to this before? If this sounds like a good idea, and if the cvs bloat won't be too much, I can start hacking this together soon. (Though it is highly unlikely this will be in 4.4, so there still needs to be a resolution as to what to do there) > Although you'd still be ahead of todays "I'm running a system supped > about dinnertime yesterday" kind of identifications. "What timezone are you in, and when do you eat dinner?" :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: so where did the space go?
On Sat, Aug 04, 2001 at 11:29:39AM +0100, Randy Bush wrote: > >> it was vmware under linux emul. > > lsof | grep /var > > # lsof | grep vmware | grep /var > vmware 489 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 489 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 492 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 492 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 493 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 493 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) This says that a process named vmware has /var open. If you want to free the inodes attached to the files that you have removed, kill whatever processes may have been writing them. -danny -- http://dannyman.toldme.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-PRERELEASE never resume from suspend
In message <[EMAIL PROTECTED]> Hajimu UMEMOTO writes: : I did CVSup and built 4.4-PRERELEASE of yesterday. Once suspend, my : laptop never resume. The kernel of Jul 21 is okay. My laptop is : called Chandra2. Dynabook 3380 SS is okay. Did someone else meet : this problem? I've not seen this problem. Can you do me the favor of trying to boot a kernel without the pccard stuff in it at all and let me know if you get similar behavior? That would eliminate at least one variable that's changed much since July 21. Thank you very much and I look forward to the results. I hope it makes no difference, but fear that it might. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: firebird oddity
hi, there! On Sat, 4 Aug 2001, Tim Kellers wrote: > So sahould I await an update, or copy those libs from older (4.3-stable) > servers and try the build again? you should make it to link against libcrypt instead of libdescrypt /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: so where did the space go?
On Sat, Aug 04, 2001 at 11:29:39AM +0100, Randy Bush wrote: > >> it was vmware under linux emul. > > lsof | grep /var > > # lsof | grep vmware | grep /var > vmware 489 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 489 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 492 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 492 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 493 randy txt VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > vmware 493 randy 11u VREG 116,262148 140673024 16 /var (/dev/ad0s3e) > > not a lot of help, or i am not seeing the clue Assuming $2 are process numbers [1], I think you may find killing those processes will release the space. [1] I don't have lsof installed here. ps will surely tell you. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
4.4-PRERELEASE never resume from suspend
Hi,
I did CVSup and built 4.4-PRERELEASE of yesterday. Once suspend, my
laptop never resume. The kernel of Jul 21 is okay. My laptop is
called Chandra2. Dynabook 3380 SS is okay. Did someone else meet
this problem?
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re[2]: SMBFS panic: malloc: wrong bucket (was: 4.3-20010721-STABLE)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2001-08-03 at 17:04:37 Boris Popov wrote: BP> Please try the attached patch. It fixes a nasty buffer overflow BP> which may cause this panic. Okay, this patch seems to solve the panic problem for me. On the previously crashing box, I cvsup'd today (to 4.4-PRERELEASE) and rebuilt everything, including the kernel with your patch, and the smbfs-1.4.1 port. Since then, I haven't been able to get it to crash anymore. :) (Keeping my fingers crossed.) I have some other remarks, though, if you don't mind: 1. When I mount_smbfs(8) a share, the mountpoint is owned by root:wheel and mode 755 by default. However, as a normal user I can _create_ files in this mountpoint, but not delete them! I would suppose that a normal user doesn't have write access with mode 755? 2. I searched for an answer to this phenomenon in the mount_smbfs(8) manpage, and it says with the -M option: "Assign access rights to the newly created connection. See nsmb(8) for theory." However, there's no nsmb(8) manpage to be found anywhere, at least not on a freshly rebuilt system. Maybe this manpage was left out while integrating smbfs into the main kernel sources? Cheers, - -- Dimitry Andric <[EMAIL PROTECTED]> PGP Key: http://www.xs4all.nl/~dim/dim.asc Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3 -BEGIN PGP SIGNATURE- Version: PGP 6.5i Comment: http://www.gn.apc.org/duncan/stoa_cover.htm iQA/AwUBO2wjgrBeowouIJajEQLtXwCg16tS7WhijvzFke/TkP33JDArXeMAoIgz FFhftYgBLJGr3IW4shs3H3Q0 =2Swi -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RELENG_4_3 calls itself -RELEASE?
Why not 4.4.1-RELEASE, 4.4.2-RELEASE, etc It's simple, to the point. Implies upgrades. Allows you to quickly determine exactly how current a particular system is with regards to patches, and follows long-standing conventions. Just my $.02 -Bill Andrew Boothman wrote: > > [Boy do I wish I hadn't started this now!] > On Friday 03 August 2001 7:49 pm, Jordan Hubbard wrote: > > > I like -BEET. It's short, means nothing, and is red. What more could > > > you ask for? :P > > > > Indeed! Well put. Unless I hear truly strong and well-reasoned > > sentiments to the contrary, I will tag and document this as the > > 4.4-BEET branch when the time comes to create it. > > While I'm usually all for nonsensical names (my own machine is called > spatula), I think we should try and pick something related, but clear. > > How do we feel about 4.4-RELEASE-PATCH1, 4.4-RELEASE-p1 or 4.4-RELEASEp1 for > the first commit RELENG_4_4 and 4.4-RELEASE-p2 for the second ? > > This idea has already been mentioned by various other people, but seems to > have been largely ignored by the rest of the conversation which, quite > understandably, became more interested in vegetables and flightless birds. :-) > > I think this is the best option for several reasons : > > 1) It makes it clear that the version you are running is basically > 4.4-RELEASE plus 'something'. > > 2) We can tell at a glance whether you are patched against a spacific > vulnerability. Security advisories can say "patched in 4.4-RELEASE-p5 simply > type 'uname -r' to determine if your system has been updated since the > vulnerability was patched" > > My original problem with the concept with the -SECURITY name was that you > can't tell if you have been patched against something. Of course, just > calling it -SECURITY doesn't make it any more obvious, but the patch numbers > do make it obvious. > > So calling a system -BEET, as much as I like the name, only addresses one of > my original concerns. Patch numbers would address both. > > -- > Andrew Boothman <[EMAIL PROTECTED]> > http://sour.cream.org > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message -- "Where's the robot to pat you on the back?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: RELENG_4_3 calls itself -RELEASE?
Fri$ Not to beat a -deadhorse, but here are my $.02 The only sensible suggestion I've seen so far is 4_3_x_RELEASE. The reason is that all the proposals I've seen (with the exception of the above and 4_3_RELEASEplX, which is not lexically bigger than 4_3_RELEASE) is merely a cosmetic change with no effect beyond the first security fix. Anyone who wants to find out whether their system has been patched will still have to resort to the old method. But there are still problems with checking the build date. Consider the following example: Admin X receives a security notification, and immediately goes to update his FreeBSD machines. Here, several scenarios can happen: 1) The cvsup server used does updates every 6 hours and/or missed the last update. Admin believes he has updated version. Admin's copy of SirCam is read by noisy hacker. 2) Two advisories are released in close proximity. Admin believes he has second fix when he in fact only has the first. Admin's site becomes the newest warez distribution point. 3) Another admin recompiles kernel for new driver. Admin X later receives advisory, and seeing that the machine is compiled post correction date, he believes that another admin fixed the problem. Site is compromised, and admin loses job/house/car/wife/kids. Here, I can offer several suggestions: 1) Have the cvs scripts add the latest commit date/time to a version.h everytime a commit occurs in a branch. Display/use it accordingly. 2) Embed the cvs $id/$FreeBSD strings in every binary. A security update tool can then be used to automagically determine whether a system has pending security issues. [I have no problems writing the aforementioned tool if we do decide to go this route] 3) Do nothing, and perhaps give more instructions in security advisories. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: I4B is broken in 4.4-PRERELEASE
This is known. I4b is MFC´d to stable and is in a "not quite here" state. This problem is being worked on. hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
