Date: Mon, 3 Apr 1995 23:19:24 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Cc: smace@metal-mail.neosoft.com, current@FreeBSD.org Subject: Re: a few patches... Message-ID: <199504040619.XAA06445@gndrsh.aac.dev.com> In-Reply-To: <5522.796979211@freefall.cdrom.com> from "Jordan K. Hubbard" at Apr 4, 95 00:06:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I would like to add a config option to enable as disable securelevel. > > the securelevel and chflags features are a major security helper IMHO. > > Are you saying you also want to come up secure? No installing over > kernels and things except when up single? > > Hmmmmm... Hmmmmmmmmmmmmm! David? When did we say we were going to > cut over after the "grace period" on this one? :-) > > Personally, I think it's not a bad idea for 2.1. I think it highly > likely that there is already going to be a BIG SIGN saying "READ ALL > OF THIS BEFORE PROCEEDING OR DIE!!" (or something to that effect) > right at the beginning of 2.1. This file will contain stuff you > _really_ want the users to read, for example the fact that system > files are immutable by default and, while FAR more secure, not > entirely without cost. > > There would probably be a number of people a lot safer because of it > if we made it a default.. Did you find an archive format to use for the bindist's that preserve this information?? Tar doesn't, I think I remeber seeing Brunce say that cpio -H newc did, but I can't verify it right now since my 2.x box is down. I am currently building and installing my own releases for customers machines due to the permission problems in this and other areas with the last few snap shots :-(. > > Also, on a totally unrelated note, I've found on at least 2 scsi drives > > I've used I need a pause right before the extended probe kicks off. > > (bt_inquire_setup_information) The minimal pause I've experimentally > > found is DELAY(450000). This is with the bt driver. I've had this patch > > in my set of "local" patches forever, but when I brought it up before, > > noone wanted it committed. Oh the horrors of yet another pause (which > > Indeed! The horror! > > I dunno.. Is this a known catagorical deficiency in certain drives? Can you again tell us more about how the failure manifests itself, and what model drives is this that is causing this. This seems very strange to me that there is a problem related to attached devices here, as we are asking the controller what it found at this stage, we are not suppose to be talking to devices. You may have slow devices that have not recovered from the SCSI bus reset, so the controller has not finished regathering this info. If that is the case then the real fix is to use SCSI_DELAY to allow your SCSI devices to become ready after a reset. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504040619.XAA06445>