Re: [RFC PATCH 0/2] Loop device psuedo filesystem
t;> Now, to get loop working in a userns, we need a way for the userns (or > >> the host!) to create a new loop-control device owned by that userns > >> and we need to tweak the loop driver to make the created loop devices > >> be owned by the userns. > > > > The patches I posted previously more or less did this using per-ns > > devtmpfs, aside from the ephimeral part. The feedback was "just do it in > > loop," so I sent these to facilitate discussing this option with > > something concrete. I personally still like the per-ns devtmpfs > > approach, but that's been nacked. > The ephemeral part might not be needed using devtmpfs if devtmpfs can > guarantee that the device nodes go away if the device goes away. I > don't know whether it can make that guarantee. > > (a) might be interesting, but I'd expect the same objections to be > > raised as for (c). And it seems to me that (b) is just a alternate > > interface for (a). > True. > >> (Note: I'm deliberately ignoring the fact that just doing this for > >> loop seems to be almost entirely useless right now: you still can't > >> mount the things.) > > You could also argue that it's useless to be able to mount things if you > > have no block device on which to mount them. We have to start somewhere. > True. > But if we take this particular route, then I can imagine a real mess > when someone wants to mount a non-loop device, and we get stuck on how > to expose the device node. Sigh. Then we deal with that horse when we have to make him sing. One way or the other, we're trying to moving forward. > --Andy Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Tue, 2014-05-27 at 03:36 +0200, Serge E. Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: > > > On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > One question about this patch. > > > > > > > > Why don't you use the devices cgroup check if the root user in that > > > > namespace is allowed to use this device? > > > > > > > > This way you can be sure that the root in that namespace can not access > > > > devices to which the host system did not gave > > > > him access to. > > > > > That might be possible, but I don't want to require something on the > > > host to whitelist the device for the container. Then loop would need to > > > automatically add the device to devices.allow, which doesn't seem > > > desirable to me. But I'm not entirely opposed to the idea if others > > > think this is a better way to go. > > > > I don't see any safe way to avoid it. The host has to be in control of > > what devices can and can not be accessed by the container. > Disagree. loop%d is meaningless until it is attached to a file. So > whether a container can use loop2 vs loop9 is meaningless. The point > of Seth's loopfs as I understood it is that the container simply gets a > unique (not visible to host or any other containers) set of loop devices > which it can attach to files which it owns. So long as the host can't > see the container's loop devices (i.e. so it unwittently mounts it when > looking for a particular UUID for /var), it won't get fooled by them. > So in this case *if* we can do it, a purely namespaced approach - meaning > that we restrict visibility of a particular loopdev to one container - is > perfect. And in that "*if" is a cloud that says "then a miracle occurs" and that miracle needs a lot more detail. How that translates into what is and is not visible and what can be mimiced in a container becomes important (to say nothing of notifying its udev). I think this loopfs thing is the answer for the loop device case, we just need to clear up those details and exorcise the devils we find in them. The loop devices are unique while they strangely seem to work with minimal leakage already (all meta data at this time). Seth remarked that, maybe, he's not paranoid enough. You know that I'm a well trained professional paranoid and I accept if people think I'm overly paranoid (is that even possible?). Even paranoids have enemies and just because you're paranoid it doesn't mean they're not out to get you. While I admit that total isolation is virtually (excuse the pun) impossible that doesn't mean I don't strive to maximize the isolation and analyze the possibilities and consequences of compromise. As I stated, "I don't see any way to avoid it". I would love to be proven wrong. It would permit my life to be so much more easy. But how can we allow this without the host in control of it and directing things to the containers? A container may request something and the host can grant it but the container should not be capable of demanding a device over and above the control of the host. How do we define the rules that say what a container can do and what it cannot do without it involving knowledge in the host (whitelisting as Seth call's it) of what is and is not allowed in the container? We already have the problem that the container devices.allow and devices.deny are major and minor based, which we know is fundamentally flawed in a udev environment. We specify major:minor in the configuration files as if they are cast in cement (which they are in all common cases) but they are not in the general case. Greg K-H hammers on this frequently. The loop devices are unique and deserve a unique solution, I'll agree. But I'm also comfortable that the host should have rules and procedures to whitelist hard devices and loop devices and manage their transfer and/or sharing into the containers. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote: > On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > One question about this patch. > > > > Why don't you use the devices cgroup check if the root user in that > > namespace is allowed to use this device? > > > > This way you can be sure that the root in that namespace can not access > > devices to which the host system did not gave > > him access to. > That might be possible, but I don't want to require something on the > host to whitelist the device for the container. Then loop would need to > automatically add the device to devices.allow, which doesn't seem > desirable to me. But I'm not entirely opposed to the idea if others > think this is a better way to go. I don't see any safe way to avoid it. The host has to be in control of what devices can and can not be accessed by the container. > Seth Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote: > Seth Forshee writes: > > > What I set out for was feature parity between loop devices in a secure > > container and loop devices on the host. Since some operations currently > > check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish > > this is to push knowledge of the user namespace farther down into the > > driver stack so the check can instead be for CAP_SYS_ADMIN in the user > > namespace associated with the device. > > > > That said, I suspect our current use cases can get by without these > > capabilities. Really though I suspect this is just deferring the > > discussion rather than settling it, and what we'll end up with is little > > more than a fancy way for userspace to ask the kernel to run mknod on > > its behalf. > A fancy way to ask the kernel to run mknod on its behalf is what > /dev/pts is. > When I suggested this I did not mean you should forgo making changes to > allow partitions and the like. What I itended is that you should find a > way to make this safe for users who don't have root capabilities. I like to think in terms of the "rootless" configurations where "root" per se is not absolute and everything is framed in terms of capabilities. > Which possibly means that mount needs to learn how to keep a more > privileged user from using your new loop devices. Not sure I got that one. As user with "more" privileges may or may not have access dependent on the congruence of the privileges. They're not heiarchial. If someone has that "priv" then they have access. If they do not, they do not. > To get to the point where this is really and truly usable I expect to be > technically daunting. Most technically non-trivial problems generally are. > Ultimately the technical challenge is how do we create a block device > that is safe for a user who does not have any capabilities to use, and > what can we do with that block device to make it useful. Concur. It boils down to privilege management and access. Absolutely concur. > Only when the question is can this kernel functionality which is > otherwise safe confuse a preexisting setuid application do namespace > or container bits significantly come into play. Ah... Admittedly it's not as late as our conversation at LinuxPlumbers last year in NOLA but... Maybe late at night but I failed to parse the above. > Eric Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Thu, 2014-05-15 at 21:35 -0700, Greg Kroah-Hartman wrote: > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > > I think having to pick and choose what device nodes you want in a > > > container is a good thing. Becides, you would have to do the same thing > > > in the kernel anyway, what's wrong with userspace making the decision > > > here, especially as it knows exactly what it wants to do much more so > > > than the kernel ever can. > > > > For 'real' devices that sounds sensible. The thing about loop devices > > is that we simply want to allow a container to say "give me a loop > > device to use" and have it receive a unique loop device (or 3), without > > having to pre-assign them. I think that would be cleaner to do using > > a pseudofs and loop-control device, rather than having to have a > > daemon in userspace on the host farming those out in response to > > some, I don't know, dbus request? > I agree that loop devices would be nice to have in a container, and that > the existing loop interface doesn't really lend itself to that. So > create a new type of thing that acts like a loop device in a container. > But don't try to mess with the whole driver core just for a single type > of device. Yeah, a lot of dynamic devices (like serial devices) can be handled in user space with the proviso that we could use some way to tickle udev and hotplug in the container with events. But the loop device is the real ugly duckling here. It's a unique case of an on-demand device with a shared control device that's not really hot-plug and not really deterministic enough to be handled purely in user space. It presents unique challenges unto itself. Makes sense to me. > greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 12:52 -0700, James Bottomley wrote: > On Fri, 2014-05-16 at 15:42 -0400, Michael H. Warfield wrote: > > > As an aside (probably requiring a new thread) we were wondering about > > > some type of notifier on the mount call that we could vector into the > > > host to perform the action. The main issue for us is mount of procfs, > > > which really needs to be a bind mount in a container. All of this led > > > me to speculate that we could use some type of syscall notifier > > > mechanism to manage capabilities in the host and even intercept and > > > complete the syscall action within the host rather than having to keep > > > evolving more an more complex kernel drivers to do this. > > > > Interesting. That could be very useful. That might even help with the > > loop device case where the mounts have to go through loop devices for > > things like file system images and builds. Very interesting... > Right, it might even make the loop case go away because now we can > present a dummy device in the container and when the host sees and > attempted mount on this, it just projects a bind mount into the > container and says I've *wink* mounted your "device" for you. Nice. That idea has prospects. I like the concept. > This idea is extremely rough, it came from a conversation I had with > Pavel (cc'd) just before OpenStack about how we might go about > eliminating our OpenVZ interception of the mount system call which > currently does all of this in kernel, so we have no code and no proof > that it's actually feasible (yet). K. I look forward to hearing more. I switched from OpenVZ years ago to LXC because OpenVZ was falling too far behind in kernel support and patches for the leading edge kernels. At the time, I was working on the MD5 signature code for the Quagga routing suite for BGP and couldn't maintain my hosts with OpenVZ and maintain my BGP connections (I have a public ASN and peer on both IPv4 and IPv6) with MD5 signatures at the same time. At the time LXC had just matured enough to serve my needs. That's interesting to note that OpenVZ did this by intercepting the mount call. Very interesting... > James Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 12:20 -0700, James Bottomley wrote: > On Thu, 2014-05-15 at 21:42 -0400, Michael H. Warfield wrote: > > On Thu, 2014-05-15 at 15:15 -0700, Greg Kroah-Hartman wrote: > > > > PS - Apparently both parallels and Michael independently > > > > project devices which are hot-plugged on the host into containers. > > > > That also seems like something worth talking about (best practices, > > > > shortcomings, use cases not met by it, any ways tha the kernel can > > > > help out) at ksummit/linuxcon. > > > > > I was told that containers would never want devices hotplugged into > > > them. > > > > Interesting. You were told they (who they?) would never want them? Who > > said that? I would have never thought that given that other > > implementations can provide that. I would certainly want them. Seems > > strange to explicitly relegate LXC containers to being second class > > citizens behind OpenVZ, Parallels, BSD Gaols, and Solaris Zones. > That would probably be me. Running hotplug inside a container is a > security problem and, since containers are easily entered by the host, > it's very easy to listen for the hotplug in the host and inject it into > the container using nsenter. In all virtualization... The host, particularly root on the host, exists as deus ex machina, the "god outside the machine". They are at my mercy. Even hardware virtualization can not protect you from the host. You wanna hear some frightening talks on virtualization, catch Joanna (miss little blue pill) Rutkowska some time. I'm particularly interesting in her takes on the "anti evil-maid attacks" and I sat in on her talks on the "north bridge" and "south bridge" malware evasion techniques. She's a good speaker who makes powerful points that makes you sweat but is pleasant in face to face conversation. I've played with her Qubes distribution a couple of times and the way it works with the TPM to insure a secure boot is interesting. But that's a completely different topic on trusted computing. OTOH, there are plenty of other things to worry about in all forms of virtualization. At Internet Security Systems, where I was a founder, fellow, and "X-Force Senior Wizard", we were looking at the ability to leak information through the USB subsystem. No isolation is perfect, especially when you have USB enabled. But that's my turf. > I don't think the intention is to label anyone's implementation as > preferred. What this shows, I think, is that we all have different > practises when it comes to setting up containers. Some are necessary > because our containers are different. Some could do with serious > examination to see if there's really a best way to do the action which > we would then all use. And I hope to contribute to the discussion of said actions. > > I might believe you were never told they would need them, but that's a > > totally different sense. Are we going to tell RedHat and the Docker > > people that LXC is an inferior technology that is complex and unreliable > > (to quote another poster) compared to these others? They're saying this > > will be enterprise technology. If I go to Amazon AWS or other VPS > > services and compare, are we not going to stand on a level playing > > field? Admittedly, I don't expect Amazon AWS to provide me with serial > > consoles, but I do expect to be able to mount file system images within > > my VPS. > Well, that's another nasty, isn't it. We all have different ways of > coping with mount in the container. I think at plumbers we need to sit > down with some of this plumbing and work out which pipes carry the same > fluids and whether we could unify them. Concur > As an aside (probably requiring a new thread) we were wondering about > some type of notifier on the mount call that we could vector into the > host to perform the action. The main issue for us is mount of procfs, > which really needs to be a bind mount in a container. All of this led > me to speculate that we could use some type of syscall notifier > mechanism to manage capabilities in the host and even intercept and > complete the syscall action within the host rather than having to keep > evolving more an more complex kernel drivers to do this. Interesting. That could be very useful. That might even help with the loop device case where the mounts have to go through loop devices for things like file system images and builds. Very interesting... > James Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Fri, 2014-05-16 at 09:06 -0500, Seth Forshee wrote: > On Thu, May 15, 2014 at 09:35:32PM -0700, Greg Kroah-Hartman wrote: > > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > > > I think having to pick and choose what device nodes you want in a > > > > container is a good thing. Becides, you would have to do the same thing > > > > in the kernel anyway, what's wrong with userspace making the decision > > > > here, especially as it knows exactly what it wants to do much more so > > > > than the kernel ever can. > > > > > > For 'real' devices that sounds sensible. The thing about loop devices > > > is that we simply want to allow a container to say "give me a loop > > > device to use" and have it receive a unique loop device (or 3), without > > > having to pre-assign them. I think that would be cleaner to do using > > > a pseudofs and loop-control device, rather than having to have a > > > daemon in userspace on the host farming those out in response to > > > some, I don't know, dbus request? > > > > I agree that loop devices would be nice to have in a container, and that > > the existing loop interface doesn't really lend itself to that. So > > create a new type of thing that acts like a loop device in a container. > > But don't try to mess with the whole driver core just for a single type > > of device. > No matter what I don't think we get out of this without driver core > changes, whether this was done in loop or by creating something new. > Not unless the whole thing is punted to userspace, anyway. > The first problem is that many block device ioctls check for > CAP_SYS_ADMIN. Most of these might not ever be used on loop devices, I'm > not really sure. But loop does at minimum support partitions, and to get > that functionality in an unprivileged container at least the block layer > needs to know the namespace which has privileges for that device. Woa! Time out... Sorry, this will be an off topic aside. Loop devices support partitions? I'd love to know how that works. I've tried several times in the past to do that but it's failed every time. I haven't been able to find any how-to in the past. This article was just a couple of years ago (after the last time I tried this): http://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/ This guy didn't use partitions directly but used the offset to the mount, which is what I had to use. Everything I found always referred to using mount offsets in order to mount partitions within a loop device. Regards, Mike > The second is that all block devices automatically appear in devtmpfs. > The scenario I'm concerned about is that the host could unknowingly use > a loop device exposed to a container, then the container could see data > from the host. So we either need a flag to tell the driver core not to > create a node in devtmpfs, or we need a privileged manager in userspace > to remove them (which kind of defeats the purpose). And it gets more > complicated when partition block devs are mixed in, because they can be > created without involvement from the driver - they would need to inherit > the "no devtmpfs node" property from their parent, and if the driver > uses a psuedo fs to create device nodes for userspace then it needs to > be informed about the partitions too so it can create those nodes. > > So maybe we could get by without the privileged ioctls, as long as it > was understood that unprivileged containers can't do partitioning. But I > do think the devtmpfs problem would need to be addressed. > > Thanks, > Seth > ___ > lxc-devel mailing list > lxc-de...@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel > -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
onsidering. > > PS - Apparently both parallels and Michael independently > > project devices which are hot-plugged on the host into containers. > > That also seems like something worth talking about (best practices, > > shortcomings, use cases not met by it, any ways tha the kernel can > > help out) at ksummit/linuxcon. > I was told that containers would never want devices hotplugged into > them. Interesting. You were told they (who they?) would never want them? Who said that? I would have never thought that given that other implementations can provide that. I would certainly want them. Seems strange to explicitly relegate LXC containers to being second class citizens behind OpenVZ, Parallels, BSD Gaols, and Solaris Zones. I might believe you were never told they would need them, but that's a totally different sense. Are we going to tell RedHat and the Docker people that LXC is an inferior technology that is complex and unreliable (to quote another poster) compared to these others? They're saying this will be enterprise technology. If I go to Amazon AWS or other VPS services and compare, are we not going to stand on a level playing field? Admittedly, I don't expect Amazon AWS to provide me with serial consoles, but I do expect to be able to mount file system images within my VPS. > What use case has this happening / needed? Hello? Dink... Dink... Is this microphone on? I've already detailed out a use case (serial USB console case) that I'm dealing with now. Now, I'm dealing with it in host user space and that's probably the correct answer there. I probably don't need kernel space help in this particular case. There's still a lot of bolt holes to fill with bolts though for the more general case. It's not the common case but it is a valid legitimate use case and one that would be expected of a "virtual machine" (VirtualBox can handle it - waste of computing cycles that it is). The loopback device case is even more common and, currently, rather inconsistent but strangle self consistent and workable. In the 80/20 case, I agree we can and should deal with this in the host user space as much as possible. That's the realm I'm working within. Seth and others seem to want more in the namespace region and I'm not convinced. But, I'm not convinced we can accomplish everything in user space either. We've got use cases and we've got problem sets. Don't give into confirmational bias and automatically discount the use cases that have been mentioned and then assume there are none. I don't know if Seth's paths are part of the answer or not. I'm not pro Seth's patches or against Seth's patches but we've got a need in search of solutions. > thanks, > greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Wed, 2014-05-14 at 21:00 -0700, Greg Kroah-Hartman wrote: > On Wed, May 14, 2014 at 10:15:27PM -0500, Seth Forshee wrote: > > On Wed, May 14, 2014 at 10:17:31PM -0400, Michael H. Warfield wrote: > > > > > Using devtmpfs is one possible > > > > > solution, and it would have the added benefit of making container > > > > > setup > > > > > simpler. But simply letting containers mount devtmpfs isn't sufficient > > > > > since the container may need to see a different, more limited set of > > > > > devices, and because different environments making modifications to > > > > > the filesystem could lead to conflicts. > > > > > > > > > > This series solves these problems by assigning devices to user > > > > > namespaces. Each device has an "owner" namespace which specifies which > > > > > devtmpfs mount the device should appear in as well allowing priveleged > > > > > operations on the device from that namespace. This defaults to > > > > > init_user_ns. There's also an ns_global flag to indicate a device > > > > > should > > > > > appear in all devtmpfs mounts. > > > > > > > I'd strongly argue that this isn't even a "problem" at all. And, as I > > > > said at the Plumbers conference last year, adding namespaces to devices > > > > isn't going to happen, sorry. Please don't continue down this path. > > > > > > I was just mentioning that to Serge just a week or so ago reminding him > > > of what you told all of us face to face back then. We were having a > > > discussion over loop devices into containers and this topic came up. > > > > It was the loop device use case that got me started down this path in > > the first place, so I don't personally have any interest in physical > > devices right now (though I was sure others would). > Why do you want to give access to a loop device to a container? > Shouldn't you set up the loop devices before creating the container and > then pass those mount points into the container? I thought that was how > things worked today, or am I missing something? Ah, you keep feeding me easy ones. I need raw access to loop devices and loop-control because I'm using containers to build NST (Network Security Toolkit) distribution iso images (one container is x86_64 while the other is i686). Each requires 2 loop devices. You can't set up the loop devices in advance since the containers will be creating the images and building them. NST tinkers with the base build engine configuration, so I really DON'T want it running on a hard iron host. There may be other cases where I need other specialized containers for building distros. I'm also looking at custom builds of Kali (another security distribution). > Giving the ability for a container to create a loop device at all is a > horrid idea, as you have pointed out, lots of information leakage could > easily happen. It does but only slightly. I noticed that losetup will list all the devices regardless of container where run or the container where set up. But that seems to be largely cosmetic. You can't do anything with the loop device in the other container. You can't disconnected it, read it, or mount it (I've tested it). In the former case, losetup returns with no error but does nothing. In the later case, you get a busy error. Not clean, not pretty, but no damage. Since loop-control is working on the global pool of loop devices, it's impossible to know what device to move to what container when the container runs losetup. For me, this isn't a serious problem, since it only involves 2 specialized containers out of over 4 dozen containers I have running across 3 sites. And those two containers are under my explicit and exclusive control. None of the others need it. I can get away with adding extra loop devices and adding them to the containers and let losetup deal with allocation and contention. Serge mentioned something to me about a loopdevfs (?) thing that someone else is working on. That would seem to be a better solution in this particular case but I don't know much about it or where it's at. Mind you, I heard your arguments at LinuxPlumbers regarding pushing user space policies into the kernel and all and basically I agree with you, this should be handled in host system user space and it seems reasonable. I'm just pointing out real world cases I have in operation right now and pointing out that I have solutions for them in host user space, even if some of them may not be estheticly pretty. > greg k-h Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Wed, 2014-05-14 at 18:32 -0700, Greg Kroah-Hartman wrote:
> On Wed, May 14, 2014 at 04:34:48PM -0500, Seth Forshee wrote:
> > Unpriveleged containers cannot run mknod, making it difficult to support
> > devices which appear at runtime.
> Wait.
> Why would you even want a container to see a "new" device? That's the
> whole point, your container should see a "clean" system, not the "this
> USB device was just plugged in" system. Otherwise, how are you going to
> even tell that container a new device showed up? Are you now going to
> add udev support in containers? Hah, no.
Oooo... I can answer that... Tell me if you've heard this one
before... (You have back in NOLA last summer)...
I use a USB sharing device that controls a multiport USB serial device
controlling serial consoles to 16 servers and shared between 4
controlling servers. The sharing control port (a USB HID device) should
be shared between designated containers so that any designated container
owner can "request" a console to one of the other servers (yeah, I know
there can be contention but that's the way the cookie crumbles - most of
the time it's on the master host). Once they get the sharing device's
attention, they "lose" that HID control device (it disappears from /dev
entirely) and they gain only their designated USBtty{n} device for their
console. Dynamic devices at their finest.
I worked out a way of dealing with it using udev rules in the host and
shifting devices using subdirectories in /dev. I got the infrastructure
implemented but didn't finish the specific udev rules.
> > Using devtmpfs is one possible
> > solution, and it would have the added benefit of making container setup
> > simpler. But simply letting containers mount devtmpfs isn't sufficient
> > since the container may need to see a different, more limited set of
> > devices, and because different environments making modifications to
> > the filesystem could lead to conflicts.
> >
> > This series solves these problems by assigning devices to user
> > namespaces. Each device has an "owner" namespace which specifies which
> > devtmpfs mount the device should appear in as well allowing priveleged
> > operations on the device from that namespace. This defaults to
> > init_user_ns. There's also an ns_global flag to indicate a device should
> > appear in all devtmpfs mounts.
> I'd strongly argue that this isn't even a "problem" at all. And, as I
> said at the Plumbers conference last year, adding namespaces to devices
> isn't going to happen, sorry. Please don't continue down this path.
I was just mentioning that to Serge just a week or so ago reminding him
of what you told all of us face to face back then. We were having a
discussion over loop devices into containers and this topic came up.
> greg k-h
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
Re: 2.6.24: Serial disabled in BIOS but serial modules still loaded (probably PnP related)
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote: > I have no COM port on notebook (without port replicator which I do not have) > so COM is disabled in BIOS. No ttyS* is detected during boot (and no device > created) but I just noticed that serial modules are still loaded. Well, this > partially defeats the purpose of disabling COM port - the intention was to > free resources by *not* loading unneeded modules ... > This may have something to do with (ACPI) PnP which apparently believes COM > is alive. > Notebook is Toshiba Portege 4000. Nice... What's this then? > 00:09 PNP0501 16550A-compatible serial port > state = active > io 0x3f8-0x3ff > irq 5 0x3f8-0x3ff is COM1 and a 16550A is the most common invocation of the vernerable serial port. I haven't seen a real 8250 in ages. the 16550 is an 8250 with larger FIFO's and better rates. Now, it's on IRQ5 instead of IRQ4 but that's all allocatable on PCI. Unless I'm missing something, it looks like you've got a COM port and it looks like it's active. Might be related to an IR port? > 00:0a SMCf010 SMC Fast Infrared Port > state = disabled > 00:0b PNP0401 ECP printer port > state = disabled : Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [2.6 patch] remove obsolete Computone MAINTAINERS entry (fwd)
On Sat, Jan 01, 2005 at 06:28:32PM +0100, Adrian Bunk wrote: > At least the mailing list is definitely dead: The mailing list use to be run by Louis Zamora who use to work for Computone. Guess I need to deal with that and move it to some of my own hardware. I hadn't realized it was out of commission. > <[EMAIL PROTECTED]>: > Sorry, I wasn't able to establish an SMTP connection. (#4.4.1) > I'm not going to try again; this message has been in the queue too long. > > I've got two patches in my queue for the Computone drivers for > > 2.6 plus three patches that apply to both the 2.4 and 2.6 kernels. I've > > got to check to see if Marcelo got around to integrating those patches > > into 2.4 and then jump onto the combined patches. > > As Shrek said... (You didn't slay the dragon?) - "It's on my > > todo list". > It seems you are still active :-) , so why is it "Orphaned"? Good question. Probably someone jumping the gun a bit because I haven't been very active on that driver lately. I do tend to drop off the radar for months at a time, depending on other projects and engagements. I haven't done updates to the driver in the 2.6 kernel and, yes, it is broken. Marcelo integrated my 2.4 patches and I've got testers running that code now. I've got a 2.6 patch that integrates those fixes and fixes some 2.6 problems. In the course of working on the 2.6 patch I stumbled onto another problem that had to be retrofitted back into the 2.4 patch which, fortunately, made it into the patch I gave to Marcelo. I'm looking over a couple of other changes that went in with that 2.4 update. I'll try and get a patch out in a couple of days against 2.6.10. > > Mike > cu > Adrian > -- >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! pgpB84aQc0l58.pgp Description: PGP signature
Re: [PATCH] catch potential null derefs in drivers/char/ip2main.c (245ac16)
0, j + >ABS_BIGGEST_BOX * > + >(box+i*ABS_MAX_BOXES)); > + } > + } > } > - } > } > #endif > > -- > Regards, > Rasmus([EMAIL PROTECTED]) > > A chicken and an egg are lying in bed. The chicken is smoking a > cigarette with a satisfied smile on it's face and the egg is frowning > and looking a bit pissed off. The egg mutters, to no-one in particular, > "Well, I guess we answered THAT question..." -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 01:33:44PM -0800, Leif Sawyer wrote: > > From: L. K. [mailto:[EMAIL PROTECTED]] > > I really do not belive that for a CPU or a motherboard +- 1 > > degree would make any difference. > You haven't pushed your system, or run it in a hostile > environment then. There are many places where systems are run > right up to the edge of thermal breakdown, and it's a firm > requirement to know exactly what that edge is. > > If a CPU runs fine at, say, 37 degrees C, I do not belive it > > will have any problems running at 38 or 36 degrees. I support > > the ideea of having very good sensors for temperature > > monitoring, but CPU and motherboard temperature do not depend > > on the rise of the temperature of 1 degree, but when the > > temperature rises 10 or more degrees. I hope you understand > > what I want to say. > I have a CPU that runs great up to 43C, and shuts down hard at 44C > so I obviously want to know how close I am to that. I don't want > rounding errors to get in the way, and I don't want changes > between kernel revs to affect it either. If the rounding errors are less than the accuracy and the reproducibility of your sensor, and you operate in that range and depend on those values, then you have no clue where you are, no matter what your granularity. You sound like the classic example of why we should NOT do this. You are foolish enough to depend on that precision and think that it's accuracy and think that it means something in comparision to the identical measurement 15 minutes later. It does not. > If we've got the bitspace, keep the counters as granular as > possible within the useable range that we're designing for. > counter = .01 * degrees kelvin Then you are being foolish. Your sensors are neither accurate to that degree nor are they reproducible to that degree. What you are describing is jibberish. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote: > The bits are free; the API is hard to change. > Sensors might get better, at least on high-end systems. > Rounding gives a constant 0.15 degree error. > Only the truly stupid would assume accuracy from decimal places. > Again, the bits are free; the API is hard to change. Twice a year I'm a judge at science fairs. Once at the local level and once at the state level. I generally judge on the senior level in the physics category. All too often I have a hard time even convincing some of my fellow judges. Each year there is at least one project where some student has used "fancy scientific equipment" to make measurements of impressive precision and beautiful results. Till you look closer and you find that their standard deviation is as large as their averages and their raw test results are all over the map. With 5 or more decimal places of precision, you find that their sample sizes and proceedures don't even support one or two decimal places, if they are lucky. If it were not for the fact that I don't think they are really that good at it, I would give them an award for "if you can't dazzle them with brilliance, baffle them with bullshit". Unfortunately, they honestly don't KNOW the difference between precision and accuracy. We often judge between a half a dozen and a dozen exhibits. This comes up every year and gets written up in comments every year. Of course, you can't be harse in judging these things and most of them really do make a legitimate effort, but it is difficult to tactfully explain to someone why their elaborate and extremely detailed results amount to utter jibberish. (To the smartasses who are about to fire off the obligatory smart remarks: Trust me, I am much more tactful with those students than I am on this list... Maybe I shouldn't be. Read that either way.) What's more apalling is that their teachers did not catch this and I have to point out the fatal flaws to a lot of my co-judges who were impressed with the scientific prowess of these individuals. No... The average person, NO, the vast majority of people, DO assume accuracy from decimal places and honestly do not know the difference between precision and accuracy. I've had comments on this thread in private E-Mail the reinforce this impression. Yes, bits are free, sort of... That's why an extra decimal place is "ok". Keeping precision within an order of magnitude of accuracy is within the realm of reasonable. Running out to two decimal places for this particular application is just silly. If it were for calibrated lab equipment, fine. But not for CPU temperatures. Yes, APIs are difficult to change. But can you honestly say that, even if we magically get off the shelf economical temperature sensors that are two orders of magnitude more accurate (without need of constant tracible recalibration - these things DO drift), that this level of precision would have any real meaning at all? I would expect the CPU temperature to vary by a few hundreths of a degree just by how many people were sweating in the cube next to me. Even the rounding error vis-a-vis the .15 is silly and irrelevant! If the sensor is +- 1 degree, you can't even measure the rounding error, even if you HAVE two decimal places. With that degree of accuracy, you are no better off than 273 with no decimal places. Worrying about rounding error on .15 when the accuracy is in the units is exactly the kind of misinformed false precision that I worry about. You actually though that the .15 was significant enough to worry about round error when, in fact, it will be impossible to measure with the equipment available in the environment of discourse. > One might provide other numbers to specify accuracy and precision. Now... That I can agree with and it would make absolute sense. Especially if we were discussing lab grade or scientific grade measure equipment and measurements. In fact, that would be a requirement for any validity to be attached to measurements of that level of precision. But that's not what we are talking about here, is it? We're not talking about a lab grade instrumentation API here, are we? If we are, then everything changes. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 08:43:06PM +0200, J . A . Magallon wrote: > On 06.08 Michael H. Warfield wrote: > > Actually, the REAL point I was TRYING to make (and doing a really > > shabby job of it) is that some of this needs a little dose of reality. > > We don't have sensors that are accurate to 1/10 of a K and certainly not > > to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when > > the accuracy of the best sensor we are likely to see is no better than > > +- 1 K is just about as relevant as negative absolute temperatures. > Lets see, somebody can develop lab equipment (dont think on PTRs or > thermistors in common world) that givee 10e-3 precission, and you are just > making linux not suitable to control that hardware. Think open. > What is the real difference between managing temperatures with a short > or a long ?. Is it really needed to fit it in a short ??!!! > I would use an unsigned long with fixed point and all done. No, we are not talking lab instrumentation here. We are talking about CPU monitoring. Lab instrumentation is a whole different issue with things like the IEEE bus and such. Lab instrumentation would require it's own drivers and interface. > -- > J.A. Magallon # Let the source be with you... > mailto:[EMAIL PROTECTED] > Linux Mandrake release 8.1 (Cooker) for i586 > Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Fri, Jun 08, 2001 at 07:33:14PM +0200, Chris Boot wrote: > Hi, > > Then you must have blown your quantum finals. Royally. ESPECIALLY > > after that statement about "temperature is nothing but the movement of > > pieces of materie". Not even close, once you get into the quant. > > > > Mathematically and quantum mechanically, negative absolute > > temperatures do exist. In quantum mechanics, temperature is expressed as > > probability populations in various quantum states. > Excuse me, but I don't think that we can get computer temperature sensors as > we know them to measure temperatures of matter in quantum states. Even if, > one day, we built a usable quantum computer which might need temperature > measurements, I doubt that the Linux kernel would run on it without being > totally rewritten. > Anyhow, I like the discussion. I love anything to do with quantum physics! Actually, the REAL point I was TRYING to make (and doing a really shabby job of it) is that some of this needs a little dose of reality. We don't have sensors that are accurate to 1/10 of a K and certainly not to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when the accuracy of the best sensor we are likely to see is no better than +- 1 K is just about as relevant as negative absolute temperatures. (Ok... Ok... Actually it did annoy me, as someone who majored in physics, to see someone else write that because physics was "a major course" for them that they could say definitively that there was no such thing and that temperature was only the movement of materials. But it was a perfect opening to try an exercise in absurdity. It just seems to have flopped. My fault.) Trying to keep this relevant to the topic of the Linux kernel, I was trying to impress people with the absurdity. That's why I closed that message about the precision being just as silly. Unfortunately, I need to be a little more explicit about things like that since it seems that my forey into absurdity went right over several peoples heads. Again... My fault. Even if we had or could, anticiplate, sensors with a +- .01 K, the relevance of knowing the CPU temperature to that precision is lost on me. I see no sense in stuffing a field with meaningless bits just because the field will hold them. In fact, this "false precision" quickly leads to the false impression of accuracy. Based on several messages I have seen on this thread and in private E-Mail, there are a number of people who don't seem to grasp the fundamental difference between precision and accuracy and truely don't understand that adding meaningless precision like this adds nothing to the accuracy. I can see maybe making it precise to .1 K. But stuffing the bits in there to be precise to .01 K just because we have the bits and not because we have any realistic information to fill the bits in with, is just silly to me. Just as silly as allowing for negative numbers in an absolute temperature field. We have the bits to support it, but why? I do agree that it should be in K, though. > -- > Chris Boot > [EMAIL PROTECTED] > #define QUESTION ((2b) || (!2b)) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Thu, Jun 07, 2001 at 08:03:58PM -0400, Albert D. Cahalan wrote: > Chris Boot writes: > > >>>> Kelvins good idea in general - it is always positive ;-) > >>>> > >>>> 0.01*K fits in 16 bits and gives reasonable range. > ... > > OK, I think by now we've all agreed the following: > > - The issue is NOT displaying temperatures to the user, but a userspace > >program reading them from the kernel. The userspace program itself can > >do temperature conversions for the user if he/she wants. > > - The most preferable units would be decikelvins, as the value can give a > >relatively precise as well as wide range of numbers ranging from absolute > >zero to about 6340 degrees Celsius ((65535 / 10) - 273) which is well > >within anything that a computer can operate. It also gives us a good > >base for all sorts of other temperature sensing devices. > > > > Do we all agree on those now? > > I nearly do. > > There isn't any need to cram the data into 16 bits. > The offset to Celsius is 273.15 degrees. > So hundredths of a degree, in Kelvin, is a better choice. [Let's see if I can argue boths sides of this fence plus a third here.] Who cares if you cram it into 16 bits. It still works. I think we can agree that negative degrees Kelvin are not relevant (outside of VERY esoteric physics circles where negative absolute temperatures are real and represent quantum mechanical states in "population inversions". i.e. Quantum mechanical temperatures hotter than infinite - reference SciAm back in the mid 1970s. I won an arguement with a PhD high energy physics prof over that point back then). Therefore, we have a 16 bit unsigned quantity which gives us a range of 0 - 65535. Translated as hundreths of a Kelvin, that works out to 0 -> 655.35 K. Ok... That's -273.15 C -> 382.20 C. And... That's roughly -524 F -> 720 F. Ok... That covers everything from superfluid Helium through MELTS GLASS with room for bobble. In 16 bits. What's the problem? Other than what's the need for two digits of precision in something that does not have even 1/100 of that accuracy? A plague of many measuring systems is "false precision". Why provide precision (the units to which a measurement can be divided or quantized) when the accuracy can not support it. I would be amazed if ANY CPU temperature monitors were any more accurate than to a degree C/K or ~2 degrees F). Hundreths of a degree K is basically silly nonsense. The precision even for tenths of a degree K or C are just not supported by the accuracy of the measuring device and are meaningless. Even if it COULD provide even something remotely similar to that level of precision in it's accuracy, is it really relevant to know the CPU temperature to 1/100 of a degree C? Looking at most temperature measuring chips today, unless you are looking at lab-quality high-precision high-accuracy sensors, you are really talking about a 12 bit sensor (+- a couple of bits) with an accuracy of not much better than +-1 C. Add the tenths if you want to be silly but returning hundreths is just meaningless jibberish. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Thu, Jun 07, 2001 at 09:30:54PM +, mirabilos {Thorsten Glaser} wrote:
> It was posted by L. K. where I now add my 0.02 EUR...
> > On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
> > > Negative temperatures do not really exist.
> > Are you really sure about this ?
> I am. I made Abitur (german degree after 13yrs of school)
> with physics being an important course, and there can not
> be any temperature less than 0 K (or -273.15°C if you want).
> This is because temperature is nothing but the movement of
> pieces of materie (and even photons, ergo energy).
Then you must have blown your quantum finals. Royally. ESPECIALLY
after that statement about "temperature is nothing but the movement of
pieces of materie". Not even close, once you get into the quant.
Mathematically and quantum mechanically, negative absolute
temperatures do exist. In quantum mechanics, temperature is expressed as
probability populations in various quantum states.
Absolute zero is the quantum state were all particles are in
the ground state. An infinite temperature is, quantum mechanically,
the condition where all states, ground and energetic, have an equal
probability of population.
A "population inversion" (a condition where the energized states
are more likely to be populated than the ground states) is at the heart
of many things we take for granted today such as lasers, masers, leds,
NMR (Nuclear Magnetic Resonance) and MRI (the medical use of NMR).
Those "population inversions" represents an "energized state"
that is more energetic than the state that would be present in a steady
state infinite temperature.
Mathematically, those states can actually be treated as negative
absolute temperatures. IOW, negative absolute temperatures are actually
hotter than infinite.
It's true that these are not STEADY STATE conditions or in
equilibrium (which is how we take advantage of populations inversions -
by their actions in returning to equilibrium), but the math still works.
Just check out a few issues of Scientific American from the mid 1970's
on "Negative Absolute Temperatures in Nuclear Magnetic Resonance" and
to the scientific journals they reference. I won an argument with
a physics prof (PhD in high energy physics) over that very issue when
I did the same thing in a 400 level senior level physics lab on NMR back
then. It's actually pretty damn simple, once you work the math, and it
agravated him that he didn't believe it but couldn't argue with the math
till he saw the work and publication from someone else. Then he conceeded
that I had him and I had been right.
IAC... Negative absolute temperatures are about as meaningless
to this particular discussion as is expressing the temperature in 1/100s
of a Kelvin which would have a precision than exceeds the accuracy of
the measuring chips by two orders of magnitude. IOW... Both are silly
and meaningless to this case. One is out of range in magnitude and one
is out of the range of accuracy.
> -mirabilos
> --
> C:\>debug
> -e100 EA F0 FF 00 F0
> -g
> --->Enjoy!
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 11:30:51AM -0700, Jeff V. Merkey wrote: > On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: > > > is curious as to how these folks did this. They exploited BIND 8.2.3 > > > to get in and logs indicated that someone was using a "back door" in > > Bind runs as root. > > > We are unable to determine just how they got in exactly, but they > > > kept trying and created an oops in the affected code which allowed > > > the attack to proceed. > > Are you sure they didnt in fact simply screw up live patching the kernel to > > cover their traces > Could have. The kernel is unable to dismount the root volume when booted. > I can go through the drive and remove confidential stuffd and just leave > the system intact and post the entire system image to my ftp server. This would be a good thing for those of us involved in investigating these sorts of things. :-/ > I have changed all the passwords on the server, so what's there is no > big deal. This server was public FTP and web/email, so nothing really > super "confidential" on it. > Jeff Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: > > is curious as to how these folks did this. They exploited BIND 8.2.3 > > to get in and logs indicated that someone was using a "back door" in > Bind runs as root. It doesn't have to. In fact, I just set up a RedHat 6.2 Honeypot a couple of weeks ago researching Bind based worms that are becoming a problem. Much to my surprise, that OOB RedHat 6.2 system ran bind as "named -u named" and was running Bind under a common user id. RedHat 6.0 runs it as root and I haven't checked 6.1 yet. Don't know about the other distros, yet. > > We are unable to determine just how they got in exactly, but they > > kept trying and created an oops in the affected code which allowed > > the attack to proceed. > Are you sure they didnt in fact simply screw up live patching the kernel to > cover their traces That would be a hint that they MIGHT have been trying to get a Linux kernel stealth module going. Several of the worms I'm looking at include the Adore LKM to hide processes, files, and sockets. That worm (as several others like it) also upgrade the version of Bind they broke in through to prevent further compromise. There will be a security advisory out on these worms, probably later this week. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFF-TOPIC] 4 ports ETH cards
On Wed, May 30, 2001 at 06:34:16PM -0300, Harald Welte wrote: > On Tue, May 29, 2001 at 09:52:41AM +0200, Fabbione wrote: > > Hi all, > > sorry for the offtopic msg. > > > > Can someone point me to a 4 ports fast/eth card solution for linux? > D-Link DFE-570 has a reasonable pricing and is well supported by the > tulip driver Just got three of these suckers and I'm about to order a bunch more (happy camper)... > > I found some cards based on the DEC 21*4* chips but when > > I asked for more details I got a strange answer from the reseller > > like that this card is able to work only half-duplex and the chip has > > only one mac-address for the 4 eth cards (really strange). > nah. And even if so, you can always change the mac-address using ifconfig. Each D-Link card has four MAC addresses (sequential). I doubt other manufactures are any different. > What the guy most likely wanted to say, is that there is only one EEprom > containing all mac adresses for the four tulip chips, which I have seen > on multiple boards What the guy was doing was having a bad case of optical rectitus. That would be typical of a "reseller" (AKA Salesman). Most would not even have a CLUE that the cards were based on the tulip chipset / driver. Because the D-Link cards were less than half of the nearest competitor [ < $180 vs > $360 for others and Compac was > $2400! ] I ordered only three not knowing for sure if they would work. Turned on the tulip driver and them suckers fired right up. Now I know they work, stock, right out of the box, and I can order a bunch more for the lab I'm working with. > > Thanks a lot > > Fabbione > > -- > Live long and prosper > - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
Hello, I'm tunning into this discussion a little late, but... On Mon, Apr 30, 2001 at 01:22:59PM -0700, Francois Gouget wrote: > On Mon, 30 Apr 2001, Jeff Garzik wrote: > > Francois Gouget wrote: > > > CONFIG_PCMCIA=y > > > CONFIG_CARDBUS=y > > > CONFIG_I82365=y > > > > Not correct -- you do not need I82365 if you have CardBus. However, if > > you are running 2.4.4 you should be ok. >Ok. I upgraded to 2.4.4 and modified my config file to be: > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > # CONFIG_I82365 is not set >But now I get the same missing symbols I initially had in 2.4.3: > Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 > Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' > Apr 30 13:19:34 oleron cardmgr[148]: + Warning: >/lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o > symbol for parameter rx_queue_len not found > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' > Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 > failed: Resource temporarily unavailable Seen this before. What version are your modutils at? Latest are 2.4.5 on kernel.org and there have been several times where I've had them slip out of rev and ended up with missing symbols. > -- > Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ > 1 + e ^ ( i * pi ) = 0 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
On Fri, Mar 23, 2001 at 10:31:49AM -0800, Gerhard Mack wrote: > On Fri, 23 Mar 2001, Bob Lorenzini wrote: > > I'm annoyed when persons post virus alerts to unrelated lists but this > > is a serious threat. If your offended flame away. > This should be a wake up call... distributions need to stop using product > with consistently bad security records. Bullshit. This is a wake up call that admins need to keep installations up to date. When a security hole is found, I DON'T CARE if it's in a package with a good security record or a poor security record. It has to be fixed and you can't put it off. Certainly not in the current climate with script driven worms like Ramen and 1i0n. Having a poor security record is a warning to the developers that it's time to clean up their act and do better. Sendmail use to be the bug of the month club. Hell! It use to be the bug of the week club. Last couple of years, it's been pretty solid. If you only went on security track record, we would all be using MMDF, which is still arguibly the most secure mail transport around. MMDF has had what? One advisory in something like 15 years of deployment? It was the default MTA in SCO Unix for years and was mandated at military installations for a long time... Still, when that one advisory comes out, you better update or you are toast. You don't solely rely on packages that have "good security records" never getting broken and then become complacent. Sites that do that are what we call "Warez" sites. :-/ > Gerhard > -- > Gerhard Mack > [EMAIL PROTECTED] > <>< As a computer I find your faith in technology amusing. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sun, Feb 18, 2001 at 12:00:03PM -0600, Gregory S. Youngblood wrote: > On Sun, 18 Feb 2001, Michael H. Warfield wrote: > > On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > > > > > On the other hand, they make excellent mice. The mouse wheel and > > > > the new optical mice are truly innovative and Microsoft should be > > > > commended for them. > > > > > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > > > optical mice. It wasn't MS's idea. > > I think their "innovation" was not requiring the optical cross > > grid mouse pad common on Sun workstations over the years. The Microsoft > > optical mouse uses variations in the surface characteristics of whatever > > it's on to perform it's function. The old optical mice just used two > > different colors of LED's (red and IR) and a special pad. This would > > actually have to scan and track the surface below it. Don't know that > > I've seen anyone do that before. > I remember being at a computer show in Minneapolis where a small company > was showing off this mouse that worked on a variety of surfaces without a > ball. I'm trying to remember if the mouse was optical or used yet another > method of functioning -- I think it was optical, though I could be > mistaken. This was in 1992/1993. I think you are correct here. I seem to recall mention of some of those earlier devices at the time of the Microsoft announcement. I seem to also recall some of the reliability problem they had. I believe they were extremely fussy about the surface they were on. > The point is, I really do not believe Microsoft made the "leap" to provide > opitcal mice without the need of the mousepad grid. Their "innovation" was > in marketing it on a wide scale though. I would agree there. They did something to improve the reliability on a wider variety of surface textures, though. Is that innovation or merely getting a good idea, that's been around, to finally work? Don't know. I didn't find the idea itself particularly innovative. The fact that they did get it to work reliable is something to be said. The marketing is a given, of course. Particularly in the face of the preception in some camps that this style of optical mouse was unreliable. > I could be mistaken - if so then let's give them their credit - but I have > a hard time believing it was their idea without some serious proof. Agreed. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 09:15:08PM -0800, Ben Ford wrote: > > > > On the other hand, they make excellent mice. The mouse wheel and > > the new optical mice are truly innovative and Microsoft should be > > commended for them. > > > The wheel was a nifty idea, but I've seen workstations 15 years old with > optical mice. It wasn't MS's idea. I think their "innovation" was not requiring the optical cross grid mouse pad common on Sun workstations over the years. The Microsoft optical mouse uses variations in the surface characteristics of whatever it's on to perform it's function. The old optical mice just used two different colors of LED's (red and IR) and a special pad. This would actually have to scan and track the surface below it. Don't know that I've seen anyone do that before. > -b Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 02:38:19PM -0800, Andre Hedrick wrote: > On Sat, 17 Feb 2001, Dennis wrote: > > good commercial drivers dont need fixing. another point. You are arguing > > that having source is required to fix crappy code, which i agree with. > > You "guys" like to have source, and there is nothing wrong with that. But > > requiring that all code be distributed as source DOES stifle innovation. > > Its as simple as that. > And when your customer gets screw because you refuse to update your binary > driver because you do not know or have had the chance to follow any > evolving API, you are going to blame us in OPEN source, right. At our office, we actually had a sysadmin suggest that the reason we had problems with viruses propagating was because they couldn't put everyone on Exchange (some of us use Unix/Linux) and that was causing the problems. Of course... Operating systems which are immune to these things are to blame for the epidemics on the ones that are suceptible. That makes sense. G Of course the availablity of quality drivers with sources are the reason for crappy closed source drivers... I can see his reasoning (isn't that scary). <;-/=/ Actually, it does make a perverted sort of sense. If we didn't have systems that didn't have these problems, nobody would think that there was anything wrong. They would just think that "of course, this is what you expect from suppliers". They would have no yardstick to measure against, so rebooting a computer once a day or having a blue screen would just be part of the normal experience. So we DO contribute to his problems! We provide a standard which he can not live up to or even pursue given the manpower and talent he may have (or not have). How is he suppose to innovate when the Open Source community is setting such a high standard for him? :->=> > Meanwhile the API changes may have boosted the performance factor and you > have screw yourself and customer base because you are to lame to see the > value of open source. > > Some time ago I proposed CLAPI, and you are one of the venders that would > benefit from such a beast. This model would have required you to LGPL a > kernel library that would have all the functional IP (that is not IP) that > is to lame to be placed into the hardware. If your hardware is so flakey > that you have to pump/prime it for operationswellyou get the > point. > > If I recall you and your company on one of the worst offenders of taking > code (GPL or not) and changing it and putting it out as binaries. I am > surprized that you have not been taken down yet. Then if someone asks for > the return of the code base and changes because they can under the terms > of the license that you removed from that code, you charge them a fee and > suggest actionable terms if any disclosure into the public form from > where it came. Well... Yeah... Of course, Andre. Can you see how that stiffles his innovation. > Regards, Later! > Andre Hedrick > Linux ATA Development Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation... [way O.T.]
On Sat, Feb 17, 2001 at 02:56:15PM -0500, Dennis wrote: > At 05:59 PM 02/16/2001, John Cavan wrote: > >Dennis wrote: > > > objective, arent we? > > > >You might ask yourself the same question... > > > For example, if there were six different companies that marketed ethernet > > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > > > with different "features" that were of value to you. Instead, you have > > > crappy GPL code that locks up under load, and its not worth spending > > > corporate dollars to fix it because you have to give away your work for > > > free under GPL. And since there is a "free" driver that most people can > > > use, its not worth building a better mousetrap either because the market is > > > too small. So, the handful of users with problems get to "fit it > > > themselves", most of whom cant of course. > >A large bulk of the investment in Linux is starting to come in from > >hardware manufacturers, notably IBM. These companies see Linux as a > >means to sell more hardware, not as a means to sell software. This is > >critical, because it means that it IS worth the money to make the driver > >perform correctly, GPL or not, because a bad driver means no sales. > Thats wrong. The eepro100 is a great example. It works for most people, so > the market for an improved one is very limited. Your market is not the > whole community, only the community that needs something better. IBM will > simply blame linux if it cant handle a situation. They arent supporting > linux, they are only taking advantage of the fact that people want it. Excuse me? A 1 billion dolar investment in Linux is not supporting it? Setting up tier 1 and tier 2 support services for a half a dozen distributions is not supporting it? Porting their AIX file systems and applications is not supporting it? Porting it to the 390 is not supporting it? You bet'cha they are taking advantage of the fact that people want it. They would be damn fools in business if they didn't take advantage of that. And that means supporting it. It's to their advantage to support it and they see it. You must have a really bizzare idea of what support means... > BSDI is distributing FreeBSD now. They havent done anything useful to > support it. They are just cashing in on it. And your point is??? > DB Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 03:08:48PM -0500, Dennis wrote: > At 07:10 PM 02/16/2001, [EMAIL PROTECTED] wrote: > >Dennis wrote: > >... > > > objective, arent we? > >Nope. Are you claiming to be? > > > > > For example, if there were six different companies that marketed ethernet > > > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > >... Rant deleted > > > >I had a problem with eepro100. > >It was fixed same night cause I had the source. > >Don't even try to compare with MickyS**t. > good commercial drivers dont need fixing. another point. You are arguing > that having source is required to fix crappy code, which i agree with. Then good commercial drivers == blivit. Ain't no such critter. They are always late and buggy and then take forever to get fixed. Nature of the close source development cycle with deadlines and project managers that say "we can afford to wait any longer, we have to ship it now and fix the bugs after release". > You "guys" like to have source, and there is nothing wrong with that. But > requiring that all code be distributed as source DOES stifle innovation. > Its as simple as that. Sorry but it's time to pull it out, smell the air, and buy a clue. There are people out there right now delivering binary modules and binary pieces for device drivers in the kernel. I'm working with one right now. They are providing partial sources with a binary library (this is the Lucent WaveLan wvlan2_cs drivers). Nothing is required. But binary drivers don't get the support from the open source people that the open source drivers get. Sounds reasonable to me. There are other binary only drivers (to say nothing of applications) both freeware and payware out there. I've got people working on some myself. So your arguement that "requiring that all code be distributed as source DOES stifle innovation" fails on it's premise because it's NOT REQUIRED. Just don't expect us to kiss your merry ass and fall over backwards meeting your demands when you DO deliver a binary only driver. If people like it, fine. If they don't, whose problem is that? The idea that nobody will pay for OpenSource software is a myth. I buy software for Linux all the time. I buy closed source software and I buy open source software. The only difference is the presence of the sources. So what. Tell me how that makes those products less innovative? Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
fore they ever get that far. > > > > > The biggest thing that the linux community does to stifle innovation is to > > > bash commercial vendors trying to make a profit by whining endlessly about > > > "sourceless" distributions and recommending "open-source" solutions even > > > when they are wholly inferior. You're only hurting yourselves in the long > > > run. In that respect MS is correct, because those with the dollars to > > > innovate will stay away. > > > >You claim that "open source solutions are wholely inferior to closed > >source solutions". > > > >H... > > > >Then why does everyone run with Apache instead of IIS? Could it be that > >IIS is a piece of crap? > > > >Feature for feature I would rather use PHP 4 over ColdFusion any day. > > > >Sendmail is MUCH more stable than Exchange. (Even if it has config files > >that look like they were designed by Carlos Castanada on a bad day.) If > >not Sendmail, there are a couple of other Open Source mail programs that > >are much superior in quality than the closed source counterparts. > > > >As for the Linux kernel being "shoddy"... > > > >Since when? > > > >I can leave my Linux box running over night and actually have it do > >things! I cannot say the same for Windows. I leave that running (same > >hardware, different OS) and it is usually dead by dawn. > > > >But your argument is even more bogus than that. > > > >It seems that you argument boils down to a couple of thing... > > > >"Closed source is better because you pay money for it." > > > >"Closed source is superior because we have a company name and you don't." > > > >Sorry, but most of the people who develop Open Source are profesional > >programmers. They just have a different motivation. > > > >Open Source is motivated by pride in what you can do and a desire to help > >others by sharing that. They don't hide behind a wall of lawyers to keep > >people from finding out what they did wrong. > > > >I found out a long time ago that most "Trade Secret" claims were bogus. > >It was either a common technique that had been adapted to a particular > >purpose or it was being used as an excuse to hide how bad the code really > >was. > > > >But my experiences with Open Source, as well as the others I know who use > >it are quite telling. > > > >If I have a problem with an Open Source program I can look at the code and > >fix it. Or I can report the bug and it will get fixed soon after. The > >programmers involved put the effort into it because their name is > >attached. > > > >My experiences with closed source companies are not as good. > > > >In many cases, I was ignored because I did not represent a fortune 500 > >company. If the problem got fixed at all, it would be months before I saw > >it and usually in a later release that I would have to pay for. (Usually > >having features added that I neither wanted or would ever use.) In some > >cases (like Microsoft security bugs) it would be treated like a public > >relations problem instead of a software and quality issue. > > > >I have also seen cases where problems were buried in development because > >"no one will find out and if they do, we will just blame Microsoft". > > > >I understand your desire to make money off what you do for a living. I do > >object to you taring what I do as somehow damaging to the software > >industry as a whole. (Especially since the closed source software > >industry has been poaching off the open source community for years. > >Microsoft seeking enlightenment with WinXP is only a minor example.) > > > >I don't see how hiding how something works adds value to the process. > > > >[EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply > >Alan Olsen| to my mail, just hit the ctrl, alt and del keys. > > "In the future, everything will have its 15 minutes of blame." > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote: > On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote: > > I did some research on the patent database and found nothing regarding such > > a patent. There's patent on word processors (not the concept but related to) > > and uses tab on the description...and that patent is from 1980. > You know XOR is patented (yes, the logical bit operation XOR). But wasn't that Xerox that had that? Yeah, the same ones that screwed us over with the compression patent that shot .gif images out of the sky. There was inovation for you. > -Dan Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Fri, Feb 09, 2001 at 01:50:04AM +, Aaron Denney wrote: > Michael H. Warfield <[EMAIL PROTECTED]> wrote: > > But, wait a minute. CNAME -> CNAME is a "must not". > Cite the RFC please. 1034 says > # Domain names in RRs which point at another name should always point at > # the primary name and not the alias. > and > # domain software should not fail when presented with CNAME > # chains or loops; CNAME chains should be followed and CNAME loops > # signalled as an error. > and > #- The answer to the query, possibly preface by one or more CNAME > # RRs that specify aliases encountered on the way to an answer. > and > # Multiple levels of > # aliases should be avoided due to their lack of efficiency, but should > # not be signalled as an error. > It's fairly clear that CNAMEs to CNAMEs are discouraged, but legal. Hmmm... Looks like I have had that just about backwards (par for the course). RFC 1912 (Common DNS Errors) makes it pretty clear that other RRs should not point at CNAMEs and that would include CNAMEs pointing at CNAMEs. It quotes your same section, 3.6.2, of rfc 1034 for justifying that. ] Don't use CNAMEs in combination with RRs which point to other names ] like MX, CNAME, PTR and NS. (PTR is an exception if you want to ] implement classless in-addr delegation.) For example, this is ] strongly discouraged: ] ] podunk.xx. IN MX mailhost ] mailhostIN CNAME mary ] maryIN A 1.2.3.4 ] ] [RFC 1034] in section 3.6.2 says this should not be done, and [RFC ] 974] explicitly states that MX records shall not point to an alias ] defined by a CNAME. This results in unnecessary indirection in ] accessing the data, and DNS resolvers and servers need to work more ] to get the answer. If you really want to do this, you can accomplish ] the same thing by using a preprocessor such as m4 on your host files. That pretty explicity states that MX records should not (and, according to RFC 974, must not) point to CNAMES. ] Also, having chained records such as CNAMEs pointing to CNAMEs may ] make administration issues easier, but is known to tickle bugs in ] some resolvers that fail to check loops correctly. As a result some ] hosts may not be able to resolve such names. That's a pretty strong recommendation to NOT point CNAMEs to CNAMEs. It's not a "must not", but it points out a seeming ambiguity in RFC 1034. The very passage you quote: > # Domain names in RRs which point at another name should always point at > # the primary name and not the alias. Doesn't that say that a domain name in a RR should always point at the primary name. Doesn't that imply (and thus semi contradict the rest of that section about loops) that CNAMEs should not point to CNAMEs? That would appear to make rfc 1034 look ambiguous. Section 3.6.2 says that RRs should always point to primary names but then goes on to discuss CNAME loops and states that multiple levels of aliases should not be signaled as an error. But then we are down to semantics and the semantics of the RFCs are defined. Should and should not are recommendations, not requirements. Must and must not are requirements. On that point, I must cede the field and admit that both CNAME -> MX and CNAME -> CNAME would appear to fall under the former and not the later. But MX -> CNAME would appear to be explicitly prohibited under RFC 974. > -- > Aaron Denney > -><- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:11:39PM -0800, H. Peter Anvin wrote: > "Michael H. Warfield" wrote: > > > > > Please explain how there is any different between an CNAME or MX pointing > > > to an A record in a different SOA versus an MX pointing to a CNAME > > > pointing to an A record where at least one pair is local (same SOA). > > > > Ah! But now you are placing conditions on it (that at least one > > pair is local). That is the very fine distinction that makes up the > > "not quite" in the "almost" above and the difference between the "should > > not" vs the "must not" in the specifications. You basically can't qualify > > it by saying "you can do this, but only if one pair is in the same SOA". > No. My point is that potential for inefficiency is not a valid reason > for banning something outright. This should be an administrative > decision, nothing more. But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME is a "should not". The "should not" leaves it to be implimentation dependent and not an outright ban. Sooo... I personally have no problem with Bind 9.x prohibiting an MX -> CNAME, but that's an implimentation issue. In case people have tuned in late, there have been some rather radical swings in Bind policy since Bind 4.x. Bind 8.x decided to ENFORCE (with a vengence) the character set policies dictated by RFC. This was (so they claimed) to protect poorly coded programs that were prone to blowing chunks and doing Chernobyl imitations on getting illegal characters in host names. Of course that also caused zones with underscores in names (more common than what you would think) to crap all over themselves when unsuspecting (i.e. failure to read warnings) admins upgraded. Bind 9.0 went back to the old 4.9 policy on characters (allow what can be entered and poorly coded programs are on their own) but started enforcing a requirement for a TTL directive and making the SOA TTL field the true minimum TTL that it was defined as (instead of a default like Bind 8 and 4 and previous used it as). I figured I was all set, since I, of course, had upgraded all MY zone files already. Imagine my surprise when 9.0 would not even load because OVER HALF of the 200+ zones I'm responsible for or host did NOT have the $TTL directive! It was assholes and elbows for a not so brief but really intense time while I updated those $@$%#@ zone files! You don't like the Bind enforcement of the DNS policy, bitch to the ISC bunch. They can be swayed (all too often, it appears). If enough DNS administrators really want to go against the "should not", maybe they will make it configurable (Actually, I didn't think it really outright prohibited it in the first place, but... Oh well...) There are lots of other things in the DNS that need to be killed DEAD with a stake through the heart like CNAME with other data (what is THAT suppose to mean). I run into lookups on sites with CNAMES and A records for a host! I suppose one can come up with a hierachial reason for doing such byzantine things, but do you REALLY want to? In applying the KISS principle (admitedly an oxymoron when it comes to DNS) I can see some people wanting to ban MX -> CNAME in general if, for no other reason, than to insure that you will do it only if you have really STRONG reasons for doing it. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 04:01:30PM -0800, H. Peter Anvin wrote: > > > Wouldn't that be true for any CNAME anyway? > > That's the point... > > In other words, you do a lookup, you start with a primary lookup > > and then possibly a second lookup to resolve an MX or CNAME. It's only > > the MX that points to a CNAME that results in yet another lookup. An > > MX pointing to a CNAME is almost (almost, but not quite) as bad as a > > CNAME pointing to a CNAME. > There is no reducibility problem for MX -> CNAME, unlike the CNAME -> > CNAME case. > Please explain how there is any different between an CNAME or MX pointing > to an A record in a different SOA versus an MX pointing to a CNAME > pointing to an A record where at least one pair is local (same SOA). Ah! But now you are placing conditions on it (that at least one pair is local). That is the very fine distinction that makes up the "not quite" in the "almost" above and the difference between the "should not" vs the "must not" in the specifications. You basically can't qualify it by saying "you can do this, but only if one pair is in the same SOA". > -hpa Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 03:47:17PM -0800, H. Peter Anvin wrote: > "Michael H. Warfield" wrote: > > > > On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > > > Followup to: <[EMAIL PROTECTED]> > > > By author:Gerhard Mack <[EMAIL PROTECTED]> > > > In newsgroup: linux.dev.kernel > > > > > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > > > > > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > > > seems like a useful setup without the pitfalls that either NS -> CNAME > > > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > > > irreducible situations; CNAME -> CNAME would require a link maximum > > > count which could result in obscure breakage.) > > > > It generally forces another DNS lookup. If you do a resolve on > > a name of type=ANY it returns any MX records and A records. If you then > > do a resolve on the MX records, you then get a CNAME and then have to > > add an additional lookup for the CNAME. If you have a lot of MX records > > and not all the servers are "up" that can add up to a significant > > increase in DNS traffic. > > > Wouldn't that be true for any CNAME anyway? That's the point... In other words, you do a lookup, you start with a primary lookup and then possibly a second lookup to resolve an MX or CNAME. It's only the MX that points to a CNAME that results in yet another lookup. An MX pointing to a CNAME is almost (almost, but not quite) as bad as a CNAME pointing to a CNAME. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001 at 02:58:30PM -0800, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Gerhard Mack <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Thanklfully bind 9 barfs if you even try this sort of thing. > > > Personally I find it puzzling what's wrong with MX -> CNAME at all; it > seems like a useful setup without the pitfalls that either NS -> CNAME > or CNAME -> CNAME can cause (NS -> CNAME can trivially result in > irreducible situations; CNAME -> CNAME would require a link maximum > count which could result in obscure breakage.) It generally forces another DNS lookup. If you do a resolve on a name of type=ANY it returns any MX records and A records. If you then do a resolve on the MX records, you then get a CNAME and then have to add an additional lookup for the CNAME. If you have a lot of MX records and not all the servers are "up" that can add up to a significant increase in DNS traffic. > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Secure Linux
On Tue, Jan 30, 2001 at 06:47:18PM +, Dale Amon wrote: > Has anyone else signed up on the NSA's secure Linux > discussion list? The idea of NSA backing the development > of a secure GPL'd linux is one I find intriguing. 1) It is not "Secure Linux", it is "Security Enhanced Linux". It's a proof of concept of adding type enforcement to the Linux kernel and looks very promising. > However I have only seen one posting. Is there anyone > "real" involved with it? Why not join the selinux mailing list and find out? [EMAIL PROTECTED] Seems to be a pretty active list. > -- > -- > Use Linux: A computerDale Amon, CEO/MD > is a terrible thing Village Networking Ltd > to waste.Belfast, Northern Ireland > -- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ECN: Clearing the air (fwd)
On Wed, Jan 31, 2001 at 06:02:17PM +, Alan Cox wrote: > > No. ECN is essential to the continued stability of the Internet. Without > > probabilistic queuing (i.e. RED) and ECN the Internet will continue to have > > retransmit synchronization and once congested stay congested until people get > > frustrated and give it up for a little bit. > Arguably so. In theory a vindictive probabilistic queueing is sufficient > (do RED but then drop -every- frame from the same route as the packet chosen > from the queue) THAT actually sounds very similar to what some ATM switches are doing when congestion results in lost cells in an IP datagram. Some time ago, a buddy up at Sandia National Laboratories was explaining the problem with congestion and IP over ATM. Once the congestion level reachs a certain point, the probability of the ATM network dropping a single cell out of the many cells comprising a complete IP datagram exceeds unity. All the transmitted cells, however, are contributing to the congestion. The datagram eventually gets retried and adds even more to the congestion. Net result is that once you pass this congestion threshold, IP throughput completely collapses and retries keep it there until higher layers fail. The answer for some intelligent ATM switches is to recognize the higher layer IP traffic and, when dropping an ATM cell in the middle of an IP datagram, to drop ALL the cells in a datagram if any of the cells are going to be dropped. That way the remaining cells are not contributing to the congestion when the entire IP datagram is going to be retransmitted anyways. Purists MIGHT argue that this is a layering violation, but it would seem to be a good one. :-/ You could call it vindictive, or maybe congestion with extreme prejudice... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, someone is trying to be funny
On Fri, Feb 02, 2001 at 03:36:46PM -0800, David S. Miller wrote: > Ok, it seems somebody is running a cron script or similar > to keep resubscribing that [EMAIL PROTECTED] address > to linux-kernel. So block them using the /etc/mail/access database for sendmail and do it with a "451" error code. The data will back up on their mail server and start clogging their mail spool till they get a clue. (Ok... 5 day expiration on the messages, but ITMT, they get several warning and error messages from each too). > So if you see the "moderation" message back from a posting > you make to linux-kernel, please dont' report it to us here > at vger.kernel.org, we know about it. > Later, > David S. Miller > [EMAIL PROTECTED] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
Damn... So much for typing too fast... Screwed it up...
On Sun, Jan 28, 2001 at 07:59:47PM -0500, Michael H. Warfield wrote:
> On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote:
> > Hi Linus,
> > Sorry to bother you. I'm trying to find where you uploaded
> > linux-2.4.1-pre11.
> > I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
> > /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
> > directories. Is it somewhere different?
> Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz
Patch was in /pub/linux/kernel/test/patch-2.4.1-pre11.gz
Cut and paste screwup. Sorry.
[...]
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.1-pre11
On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote: > Hi Linus, > Sorry to bother you. I'm trying to find where you uploaded > linux-2.4.1-pre11. > I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the > /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/ > directories. Is it somewhere different? Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz > Also, Alan, I grabbed your patch-2.4.0-ac11.gz file from your directory on > ftp.kernel.org. Does this contain the updated VIA IDE support that Linus > was talking about in the 2.4.1-pre11? > I'm thinking either kernel.org hasn't posted the 2.4.1-pre11 or I totally > misunderstand the directory layout on kernel.org. Close... > A URL to the right patch or, preferably, full source for 2.4.1-pre11 would > be great. > Thanks, > David D.W. Downey [...] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Support for 802.11 cards?
On Sun, Jan 28, 2001 at 05:07:33PM -0500, John Jasen wrote: > On Sun, 28 Jan 2001, Mike Pontillo wrote: > > I was wondering what 802.11 PCI cards anyone knows of that run > > under Linux-2.4. (or 2.2 for that matter) > I _think_ a good many of the 802.11 wireless ISA and PCI cards are just > bus to PCMCIA adapters, so it would be a question of whether or not the > PCMCIA card is supported and if the bridge is supported. Last I knew (straight from the Lucent people), the ISA bridge card worked fine and the PCI card did NOT work at all. I've since confirmed that, first hand, myself (I currently have the ISA bridge in operation) on the 2.2 kernels. The ISA bridge also works on the 2.4 kernels but I have not retested the PCI bridge on 2.4. The Lucent people claim that the Linux pcmcia people are aware of the problem. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Kernel Janitor's TODO list
On Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse wrote: > [EMAIL PROTECTED] said: > > Please send additions and corrections to me and I'll try to keep it > > updated. > Anything which uses sleep_on() has a 90% chance of being broken. Fix > them all, because we want to remove sleep_on() and friends in 2.5. And friends meaning "interruptible_sleep_on"? Great... I've got a driver with about a half a dozen of them. Point me at the Doco to fix please? > -- > dwmw2 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: hotmail not dealing with ECN
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote: > On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote: > ... > > An attack against an Xray system is much more likely to come from inside the > > companies network. > ... > We are not talking about attacks here, we are talking about undefined > behaviour when (perhaps poorly designed) systems encounter network > packages that use new or experimental features: I have seen MRI scanners > panic when they received SNMP queries and SNMP has been around for ages! Couple of years ago I did a security advisory on OS/9 (the Microware OS that was originally designed for 6809 processors). It had become quite popular for embedded controllers. I think at the time it was ranked one of the top three embedded controller operating systems and was used in a large number of Allen Bradley controllers. Read that last statement as saying that it was in a GOD AWFULL number of HVAC controllers and factory automation controllers around the entire world. We stumbled onto a flaw in the protocol stacks in OS/9 and it couldn't handle being hit with an ICMP redirect. The incoming stack didn't properly recognize it and created some weird state in the outgoing stack. The next time the controller tried to transmit something, the controller hung leaving whatever it was controlling in what ever position it was in, no matter what the consequences. This was "discovered" the hard way at a site where the network people had not even realized that all of these controllers were connected to the main corporate network. Envision hundreds of controllers suddenly freezing and an entire plant rapidly grinding to a complete halt. My contact at Microware told me that they never anticipated having those controllers hooked up to a general purpose network and OS/9 was designed for such a small footprint (Hey, I had a multitasking, multiuser, dial-in system running on a RadioShack CoCo with 64K of memory running OS/9) that they had no room for handling ICMP redirects so they hadn't coded it into the stack. Multiple mistakes and assumptions resulted in a security advisory warning about potential threats to human health and safety. They were having a bad day... Especially when CNN called them. :-/ (They had been notified over 6 months prior to the publication of the advisory, BTW...) That advisory concluded to isolate all embedded controllers to insulated subnets and configure all routers to refuse to pass ICMP redirect packets. Anyone want to take bets if it's been done to any great extent? It will take some factory being knocked on it's ass and making CNN, and even then most people won't take action because most of the admins don't know what's on their networks in those environments. Upgrading a lot of these old controllers also meant physically removing and replacing EPROMS. (One claim to fame for OS/9 is that it was totally PIC and could be copied straight into EPROM and run equally well from EPROM or RAM at arbitrary addresses.) That's even assuming you knew where all your controllers were and how to get to them! So... Yeah... I can understand what can happen when unknown packets reach devices that were not designed to handle them. Bad Juju... And embedded controllers are a hell of a lot more plentyful than X-Ray machines. > Yours, > Dominik Kubla > -- > A lovely thing to see: Kobayashi Issa > through the paper window's holes (1763-1828) > the galaxy. [taken from: David Brin - Sundiver] Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
On Fri, Jan 26, 2001 at 01:52:26PM -0800, Stuart Lynne wrote: > In article <[EMAIL PROTECTED]>, > James Sutherland <[EMAIL PROTECTED]> wrote: > >On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: > >Except you can't retry without ECN, because DaveM wants to do a Microsoft > >and force ECN on everyone, whether they like it or not. If ECN is so > No, he just wants them to ignore it like they are supposed to do if > they don't know what it is. > >wonderful, why doesn't anybody actually WANT to use it anyway? > Because they are stupid and don't want to take the time and energy > to upgrade their systems. > Most ISP's have the generic rule, if it ain't broke, don't fuck with it. > Even the mighty microsoft learned just two days ago what happens if you > make mistakes changing routing information. No... Microsoft learned, just two days ago, something that has been part of best practices for over 15 years. Do NOT put all of your DNS servers on the same network! The technical error may have triggered the meltdown but if they had distributed their DNS the way they were suppose to, it would have NOT taken them totally out. It wasn't the technician's mistake. It was the single point of failure (and subsequently the single point of attack). He just triggered it. > -- > __O > Lineo - For Emedded Linux Solutions _-\<,_ > PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 > Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Which Bind version..
On Mon, Jan 08, 2001 at 12:56:37PM +0500, Mike wrote: > Hi!! > I wanna install Bind on my DNS. Which Bind version is most stabel and > secure. 9.0.1 is the latest release in the 9.x series and if you are interested in "SecureDNS", that's the way to go. I'm currently running 9.1.0beta2, and it seems rock solid to me. There is also 8.2.2P7 if you want to stick the the older 8.x series, but I certainly wouldn't if I were setting up a new DNS server. The 4.x series is totally deprecated at this point. Personally, I wouldn't use anything less than 9.0.1 and I currently support over 100 domains on my servers (my partner runs a hosting service). > Regards, > Nauman Ansari Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 10:30:14PM -0500, Gregory Maxwell wrote:
> On Sun, Jan 07, 2001 at 08:22:28PM -0500, Michael H. Warfield wrote:
> > I already run several sugarplum sites with teergrubes. I also use
> > various blackhole lists and take other action against spammers, including
> > blocking entire rogue domains. If that rogue domain happens to be a two
> > letter TLD, so be it. If it gets bad enough, maybe they'll fix it.
> You are suggesting that it is acceptable to implement technological
> barriers to a minority expressing speech that is unacceptable to the
> majority. This is not acceptable.
No... I'm say that their right to free speech does not trump
my right to not have to listen to it or download it and I determine
the criterion, they don't. I have, in my right to free speech, the
right to say screw off, I don't want to hear it.
> When you subscript your mailbox to list of 'spammers' to avoid associating
> with them, with the knowledge that you may lose some valuable mail, that is
> fine.
Excuse me??? Clue alert! I'm not subscribing anything to any
spam mailbox. I'm not doing jack shit to subscribe myself to anything
to do with them. I am leaving bait around for them to screw themselves,
but I certainly have the free speech right to do that, now don't I?
I don't go to them and say "subscribe all these addresses". I don't
say to them, send E-Mail here. They are trespassing on my systems,
clearly stepping over well delineated boundries.
I'm really lost by your reasoning on this one. "Subscribing my
mailbox to a list of 'spammers' to avoid associating with them, with the
knowledge that you loose some valuable mail" makes absolutely no sense
what so ever. The legitimate mail I may or may not loose has no bearing
on the sugarplum or teergrube systems (which is what I'm assuming that
you are elluding to).
> The situation is similar to not visiting a gay bar if you don't like
> homosexual people. However, that is not what you are doing blocking whole
> countries. That is like building concrete barriers around cites to punish
> them for not oppressing their own minority citizen ("I'm going to block your
> whole country until you outlaw this class of speech I find offensive").
Tough... I find the speech offensive, I don't have to listen
to it. If I find that the level of offensive speech from a particular
source exceeds all value, then I have the right to block it. They don't
like it, they have a right to change. Like I said... I don't take
active action against them. They have to come to me. They come to
my web site and step over my limits and contact my systems. I'm not
going to them.
> Spam is not good, but destroying freedom is worse. I suggest that every
> person who is eager to use oppressive technological measures to stop spammers
> please consider the potential wider consequences.
Destroying my freedom is just as bad. I have the freedom to
choose and I have the freedom not to be plagued by the vermin who have
harvested my addresses and are using them in a way that violates my
acceptable use on my addresses.
> Today the majority thinks spam is wrong, today you are a part of the
> majority. The Internet should always avoid the tyranny of the masses, even
> when it's operators are a part of the 'mass' today. Tomorrow the issue will
> not be spam, and you might not be in the majority.
Not a problem. Won't be the first time and won't be the last time.
I deal and so shall they.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 06:31:11PM -0700, Matt Beland wrote: > Thereby killing how many hundreds of innocent people? China doesn't much > believe in fining minor offenders, remember. > You don't like Spam? Join the club. Blacklisting any domain - ANY domain - > for spamming, unless you can absolutely prove that no legitimate email has > ever been sent from that server, is completely unacceptable. You complain > about the wasted time and bandwidth caused by Spam messages - how much time > do you waste every year blocking legitimate messages? Not nearly as much time wasted as the time and bandwidth that gets wasted for doing nothing. The problem is bad enough. Letting them run wild will make the cesspool stink even worse. The sites that get blocked are misconfigured and need to be fixed. They're just getting a little more incentive. Most of the spam I reject gets rejected before the data transfered (blackhole tagged). That preserves my resources. Spot checking indicates that I'm loosing very little legitimate mail. Example... By using DULS RBL, I block the majority of directed mail from dialup sites. Spot checking reveals that my kill ratio is better than 100:1 on that (100 spam to less than 1 legit). Only site I have ever needed to code an exception for was Bruce Peren's Map site when he had to move it to a personal connection. (BTW... I spot check by running some sites configured to drop rejected mail in spam cans and occasionally do this on my main server. I also check logs for legit traffic being rejected.) Anyone who hits one of my teergrubes has absolutely no legitimate business what so ever! There is not a single legitimate address on those tarpits. Oh! The poor sucky spammer got stuck talking to a few thousand addresses on a machine that takes three minutes to tell him "OK". Sorry, no tears... They get exactly what they deserve. They got the addresses by violating the robots.txt rules and harvesting poisoned pages. That's the only way they will find those addresses. Tough. BTW... I'm seeing several spam address harvestors chewing on my sugarplums every week. It's getting close to seeing more spam address harvestors than seeing legitimate search engines through my web sites. Mind you... What I do is actually pretty minor. The potential for real damage really exists. Several anti-spam sites jokingly suggest that rejection codes should be "4xx" codes instead of "5xx" codes. Think about that for a second... They haven't transferred any data to you but you tell them to hold that data and try back later (4xx codes signify temporary errors that may be retried). So that data sits on their system until their final retries time out several days (5 days typical) later. Now... Take that and take advantage of the old "percent hack" that thousands of servers around the net still support (and are vulnerable open relays in and of their own right). Send a message to each of those servers pecent hacking a huge message at the chump you want to target with a final address of a system that blocks him with a 4xx code. With little effort you can totally shut down his mail spool and backup mail onto the percent hackable servers. Even if he manually cleans his spool, he's got another shit load or two waiting for him. Sites which permit open relaying are vulnerable to the 4xx code attacks. They have an open death trap DoS security vulnerability on them. The fact that we don't take advantage of it, means we're the nice guys. We only give them 5xx codes and tell them to go away... I have the right to decide, based on what ever criterion I chose, to accept or reject E-Mail. For the sites that I administer for a large E-Mail base, that needs to be in accordance with the established policies. In most cases, I have a hard time coming up with rules strict enough to adhere to those policies while still keeping the mail flowing. The owners of those sites have a right to dictate those policies. Not the senders. > Matt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 07:27:45PM -0500, Gregory Maxwell wrote: > On Sun, Jan 07, 2001 at 06:16:15PM -0500, Michael H. Warfield wrote: > > 99% of mine is from China (either *.cn or 163.com or some other > > numbering .com or .net. The .org is frowned upon in China - the TLD of > > protestors and disidents). Half of what's left comes from either .kr > > or .br. I'm fully in favor of an Internet Death Penalty against those > > TLD's and associated domains till they clean up their acts. > Yea! > Next we'll take care of those subversive linux bastards that clog up our big > pipes with their communist kernel downloads! > Unsolicited commercial email is a problem. However, many of the 'solutions' > are worse. Search for teergrube for a less subvertible aid. I already run several sugarplum sites with teergrubes. I also use various blackhole lists and take other action against spammers, including blocking entire rogue domains. If that rogue domain happens to be a two letter TLD, so be it. If it gets bad enough, maybe they'll fix it. > You can pile on technological 'fixes' as much as you want, but no > technological measure that does not totally oppress free use of the Internet > will be affective. Education is the only solution, spam will continue as > long as it is profitable. Actually, the most fun with the Chinese is to take advantage of their "four horsemen of the Infocalypse". Ours (in the US and many other western countries) is "Drug Dealing", "Money Laundering", "Pedophiles", and "Terrorists". In China it's "Taiwan", "Tibet", "Dissidents", and "Pornography". In discussing the Spam problem with some Chinese officials in Beijing back in June of last year, they were really ho hum about the whole thing till I mentioned that a lot of the spam being relayed out of the Phillipeans through Chinese sites was promoting pornography. That got some people sitting up real tight. They didn't care that their pipeline in and out of China was oversubscribed by an order of magnitude and spammers were clogging it with trash, but they damn well did care if that trash had anything to do with pornography. I've heard some people suggest that they mail message back to spam sites in China thanking them for their mail and including some propaganda on Taiwan or Tibet. Maybe some Falun Gong literature would be nice... Attack a social problem by turning another social problem loose... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: .br blacklisted ?
On Mon, Jan 08, 2001 at 12:03:19AM +0100, Pedro M. Rodrigues wrote: >Lucky b*st*rd! ;-) My spam is mostly from USA. Just deleted 78 > of those, and only 7 seemed to be from abroad. I wish i could block > .com ... ;-) 99% of mine is from China (either *.cn or 163.com or some other numbering .com or .net. The .org is frowned upon in China - the TLD of protestors and disidents). Half of what's left comes from either .kr or .br. I'm fully in favor of an Internet Death Penalty against those TLD's and associated domains till they clean up their acts. > Pedro > On 7 Jan 2001, at 17:53, John O'Donnell wrote: > > Only on my company's e-mail server. My company typically gets "zero" > > emails from outside the US. If I get a piece of spam (sorry they are > > typically from outside the US), I just block the entire .com.br > > domain. I get far less SPAM now! I cannot express how much I loathe > > SPAM! I have taken this one in particular out just for you :-) I > > am the only one at my company really active on the internet.. > > apologies Johnny O Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Good mailing list.
On Tue, Jan 02, 2001 at 09:24:11AM -0500, Timothy A. DeWees wrote: > Hello, > Since it takes quite a it of time for me to deal with news groups, could > someone please point me to a _LINUX_ news group that could help me with > password sync between Unix and Windows. I am using Microsofts password sync > tool that comes with SFU 1.2. I know I sould ask Micr$loth, but I have been > for two mounths and thay refuse to help me. I get ignored in the Micro$loth > list, and I have a deadline. Besides, I have found that most linux hackers > know more about Micro$loth then the _GOOD_ people at Micro$sloth. You might be better off asking this up on one of the Samba mailing lists. We have options in Samba for simultaniously changing both the Windows NT password hashes and the Unix hashes where Samba is providing NT encrypted password authentication. You can also use pam_smb to use the NT password hashes for Unix password validation as well. In either case, it's more a generic Unix thing than it is a specific Linux thing and you're more like to find your answers in the Samba project. Try [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] > Thanks, and sorry for any disturbance! > -- > Kind Regards, > Timothy A. DeWees > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [rapela@sipi.usc.edu: SYN_SENT block]
On Wed, Dec 27, 2000 at 05:38:10PM -0800, Joaquin Rapela wrote:
> I forgot to mention. I am running RedHat 6.2 and the kernel release is
> 2.2.14-5smp.
It depends upon what that spider is doing. You didn't exactly
elaborate on what it was. Is it a "web spider" or a "spam harvestor"
(web spider looking for E-Mail addresses) or something else? You cross
into the wrong areas, and some sites will cut you off (warning ALWAYS
obey robots.txt). If you get cut off by a firewall, you will most often
get dropped and every SYN packet you send will get ignored and you
will be stuck in SYN SENT state till you time out. This is deliberate
on our part. Someone trespassing out of bounds in my network gets
cut off at the firewall and gets nothing back... That does several
things that I WANT. It blocks them from determining anything residing
behind my firewall, it blocks them from determining the state of
ports and servers, it slows them down when scanning my address
space, and it makes my entire network look like it is totally
unpopulated (and uninteresting). I like that... :-)
Access the wrong URL and some IDS (Instrusion Detection System)
fires and you can no longer contact anything in an entire netblock. You
won't even get an error back. Hell! We don't want to tell you we are
refusing to talk to you. We want you to ignore us and go away like we
didn't even exist!
That being said, if you reach a dead site (not currently reachable
for one reason or another) this can also happen. Normally you might
expect an ICMP UNREACHABLE. If the target site is behind a firewall
that blocks ICMP UNREACHABLE {HOST|NET_UNREACHABLE} (lots do this) you
will hang in that state till you time out because you never got an
error back from a down system.
That's life in the big city... You run a spider, you can expect
that. Sites will be hostile to you and cut you off. If you trespass
out of bounds into some honey-pot or sugarplum, you get what you
deserve, that's why we set these traps up on our servers. My robots.txt
will warn off anyone legitimate. Some spider straying beyond what is
allowed by robots.txt is going to hit a trap and be blackholed. It's
exactly what it deserves.
> Joaquin
> - Forwarded message from Joaquin Rapela <[EMAIL PROTECTED]> -
> Date: Wed, 27 Dec 2000 16:25:18 -0800
> From: Joaquin Rapela <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: SYN_SENT block
> User-Agent: Mutt/1.2.5i
>
> Hello,
>
> I am not a linux kernel guy. I am running a spider that sometimes gets blocked
> for long periods of time. I run a "netstat -nto" and I observe a socket in
> state SYS_SENT that seems to be blocked. Its timer keeps on incrementing.
Yup... You sent a SYN (and maybe a couple of retries) and got
absolutely nothing back. Zip. Zero. Ziltch. Of course it's timer
keeps incrementing. How else would it time out?
> Is there any way to avoid this blocking? Is this a bug in the kernel or
> something wrong in my TCP/IP configuration/settings.
Neither. You are working fine. You are being deliberately
torpedoed by systems or firewalls configured to return no error and
to ignore you. Deal.
> Thanks in advance, Joaquin
> - End forwarded message -
>
> --
> Joaquin Rapela
> PhD Student, Signal and Image Processing Institute
> University of Southern California
> 3740 McClintock Ave, EEB 424
> Los Angeles, CA 90089-2564
> email: [EMAIL PROTECTED]
> tel: (213) 740-6430
> fax: (213) 740-4651
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Any idea about this - SCSI Scanner...
Hey all!
I'm just now getting around to trying to get my SCSI based scanner
(Mustek MFS-6000CX) working with Sane and ran into a problem. The Linux
kernel doesn't seem to be recognizing it at all. The Adaptec BIOS
shows it on the bus prior to bootup (target 2 on the SCSI bus) but
when the kernel comes up it sees all the drives and the CD-RW drive and
the ZIP drive, but doesn't seem to see ANYTHING on target two (consequently
the SCSI generic device is not seeing the Scanner). The Scan app
"find-scanner" also reports no scanner on the SCSI bus.
Anyone know why the Adaptec board and BIOS would see the scanner
but the Linux kernel would not?
For reference... I'm running 2.4.0test12. I'm about to set up
to retest against 2.2.18 as well.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: The NSA's Security-Enhanced Linux (fwd)
On Fri, Dec 22, 2000 at 06:39:49PM +, Alan Cox wrote: > > These folks are good at what they do and the code is GPL. > > It is worth starting to consider whether this code, or code > > from one of the other security-enhancement projects, should > > be included in the standard kernel for 2.6 or 3.0. > I think this is a good point. Its actually a nice testimonial for free > software that its finally got the NSA contributing code in a way that everyone > benefits from and which may help cut down computer crime beyond government. > (and which of course actually is part of the NSA's real job) > > > It's just code like everone else produces. > > So people looking at it may find bugs and vulnerabilities the > > implementers hadn't considered. Great. > Yep. Im sure all sorts of people will be finding bugs in it because they are > looking for secret NSA backdoors so why discourage them 8) Now that's a real damn good point that I hadn't thought of. With everyone so paranoid about what backdoors they may have left (like they would be that crazy to put them in and put it out in plain view for everyone) that the code should end up getting a real good review for bugs as well. :-) Such a deal. :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The NSA's Security-Enhanced Linux (fwd)
On Fri, Dec 22, 2000 at 10:39:03AM +, Alex Buell wrote: > On Fri, 22 Dec 2000, Mike A. Harris wrote: > > The result is available for download at the above URL as well. Has > > anyone here toyed with it already ? > > I'd eyeball the sources for backdoors, if I were you. > Hey, this is open source here. We'll "many eyeball the source". That's a given... :-) > Cheers, > Alex > -- > Here, have some homemade chocolate biscuits. > http://www.tahallah.clara.co.uk Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
On Fri, Dec 22, 2000 at 01:24:44PM +1100, Mike OConnor wrote: > Hi > I would like to point who ever is in charge of the TCP stack for the linux > kernel at a site which claims to have a method of eliminate denial of service > (DoS) attacks > http://grc.com/r&d/nomoredos.htm > With my limited unstanding of TCP and DoS attacks this would seem to be the > answer, instead of a work around. Obviously written by someone with no real world experience with DoS attacks. He seems to think that the majority of DoS attacks are SYN floods and disregards all the rest by saying this will eliminate DoS attacks. In fact, SYN floods have been largely ineffective for some time now and comprise a very small percentage of attacks now. From all appearances, his approach would have no effect on attacks like NAPTHA which try to take advantage of more advanced states in the TCP state machine. He actually should take a look at the "Cookie Crumbs" attacks against ISAKMP/IKE (IPSec) which suffer from the same first packet saved state problem. Those guys haven't solved that problem and that's even a security protocol! Maybe he could be some help there (or learn something). We probably see more incidents of TIES bombing (sending packets with "\r+++ATH0\r" in payloads) to hang up modems than we see SYN flooding lately (IMHO). I recently helped and ISP that was virtually shut down by someone TIES bombing them with ping packets containing the TIES hangup sequence. Once we got THEIR modems fixed, the TIES bombs were hanging up their customers modem's (the ICMP Echo Reply) and we had to design a TIES Bomb packet that would reset the vulnerable customer modems to a safe S register value... Grrr... Quite frankly... My favorite DoS attack is NISNuke (which I researched and documented). His approach would have exactly zero effect in mitigating an NISNuke attack and I can take out and entire network with it (all you need is NIS and finger on the same large network). So he can NOT claim to eliminate DoS attacks since I have a small arsenal of them which would be untouched by his approach. While some DDoS (Distributed Denial of Service) attacks do incorporate SYN flooding, their most profound effect is in the bulk attack areas such as Smurf flooding (ICMP echo to broadcast addresses while spoofing the return address as the targeted party) and UDP data overloads. Those have other solutions (such as router filters which prevent spoofing) which we can't even get implimented, much less a tcp stack state machine redesign! He's got a solution (and an ineffective one at that) that's really in search of a problem. It's highly unlikely that it would even make a miniscule dent in the DoS problem. That's even assuming that it would work (which others such as Dave Miller have stated that it wouldn't). He gets a "nice try" but in the long run it boils down to the expression in the IETF... You vote with working code. Let's see the code in operation and see how it works and stands up. If it works and it more robust in the face of ongoing attacks, all hail! Kudos for all around. If not, then don't tell us how it should be. Demonstrate with working code. I didn't seen ANYTHING on that site but a description of how he thought it should work. Vote with working code... > Cheers > Mike OConnor Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
Hello all!
On Wed, Dec 20, 2000 at 01:08:07PM -0500, Michael H. Warfield wrote:
> On Wed, Dec 20, 2000 at 12:52:27PM -0500, Michael Rothwell wrote:
> > "Michael H. Warfield" wrote:
> > > You can use spf to add some stateful inspection for PORT mode
> > > ftp. Personally, I like the masquerading option better, though.
> > Can you give an example of using MASQ selectively? I have real addresses
> > on both sides of the firewall, but want things like FTP to work
> > correctly. I think the IPChains HOWTOs are just a little terse. :)
Michael Rothwell kindly pointed out to me in private mail that
I SCREWED UP (he didn't say that, I did) the copy-and-past on one of
the command lines and left out a "little detail"...
> modprobe ip_masq_ftp
> ipchains -A forward -p tcp -s {Source Addresses} -d 0/0 21
This should have been:
modprobe ip_masq_ftp
ipchains -A forward -p tcp -s {Source Addresses} -d 0/0 21 -j MASQ
DOH! Sorry!
> Seems to work for me (mine includes a "tag" and a policy route
> rule to send it out my cable modem that I've left off here)...
> If you don't load the ip_masq_ftp module, you WILL get illegal
> port errors on the PORT commands.
> > Thanks!
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
On Wed, Dec 20, 2000 at 12:52:27PM -0500, Michael Rothwell wrote:
> "Michael H. Warfield" wrote:
> > You can use spf to add some stateful inspection for PORT mode
> > ftp. Personally, I like the masquerading option better, though.
> Can you give an example of using MASQ selectively? I have real addresses
> on both sides of the firewall, but want things like FTP to work
> correctly. I think the IPChains HOWTOs are just a little terse. :)
modprobe ip_masq_ftp
ipchains -A forward -p tcp -s {Source Addresses} -d 0/0 21
Seems to work for me (mine includes a "tag" and a policy route
rule to send it out my cable modem that I've left off here)...
If you don't load the ip_masq_ftp module, you WILL get illegal
port errors on the PORT commands.
> Thanks!
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
On Wed, Dec 20, 2000 at 08:51:34AM -0800, David Lang wrote: > On Wed, 20 Dec 2000, Michael Rothwell wrote: > > Date: Wed, 20 Dec 2000 11:30:15 -0500 > > From: Michael Rothwell <[EMAIL PROTECTED]> > > To: Michael H. Warfield <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: iptables: "stateful inspection?" > > "Michael H. Warfield" wrote: > > > I think that's more than a little overstatement on your > > > part. It depends entirely on the application you intend to put > > > it to. > > Fine. How do I make FTP work through it? How can I allow all outgoing > > TCP connections without opening the network to inbound connections on > > the ports of desired services? > > > for the issue of outbound TCP connections you can set ipchains filters > based on the Syn flag to prevent inbound connections. > for FTP I don't know off the top of my head how to do it when not > masquerading, when NAT is turned on load the FTP masq helper module and it > will allow you to do ftp out with no problems. You can use spf to add some stateful inspection for PORT mode ftp. Personally, I like the masquerading option better, though. > the real point that you need the stateful filtering is on UDP ports. for > that again I don't know any way when not doing NAT, but when NAT is > enabled it does do basic stateful filtering (but watch out for timeouts) Stateful filter also helps block FIN scans and other stealth scans, as well as some other esoteric attacks (fragmentation attacks, Ping'O Death, etc...). There are other ways to deal with those attacks as well, but stateful filtering helps. You also need it if you want to take advantage of some ICMP as well. Big thing for me about NetFilter over IPChains, in addition to statefull inspection, is the fact that we finally have an IPv6 aware firewall now. I've been chomping at the bit to get on IPv6 but couldn't till I had working firewall code for that. > David Lang > > > Yes it does. It's clearly stated in all the documentation > > > on netfilter and in it's design. Read the fine manual (or web site) > > > and you would have uncovered this (or been run over by it) for yourself. > > > > > > http://netfilter.filewatcher.org/ > > > > Thanks. > > > > -M Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
On Wed, Dec 20, 2000 at 11:30:15AM -0500, Michael Rothwell wrote: > "Michael H. Warfield" wrote: > > I think that's more than a little overstatement on your > > part. It depends entirely on the application you intend to put > > it to. > Fine. How do I make FTP work through it? How can I allow all outgoing > TCP connections without opening the network to inbound connections on > the ports of desired services? Passive mode ftp works great for me. You can also tack spf on top of IPChains and get port mode working if that's really part of your requirements. If you really want to get sexy, you can use the MASQ code to masquarade and handle the FTP for you. Personally, I like the MASQ trick better than using spf and enabling PORT mode. Policy routing helps out there as well where you want to masquarade some services and let others pass untampered. (Actually you only REALLY need policy routing if you are also playing tricks with the routing when you masquarade.) I use policy routing anyways, so I can route outbound ftp and http out a big fat unreliable broadband pipe while protecting my static addresses through my nice reliable ISDN channels. Your second question doesn't even seem to make sense to me. Doesn't make sense as in either I don't understand your question or the answer is so obvious if I do. You allow outbound "SYN" packets and block all (or only allow appropriate) inbound "SYN" packets (-y option on the ipchains rules). Or did I misunderstand your question? In my case, inappropriate inbound SYN packets get portforwarded up to Abacus PortSentry on the firewall to deal with port scanners. Yes, that setup still does allow people to do "FIN" scans and other stealthy scans, but with Abacus PortSentry running in front of everything and shutting down rogue sites that try to scan me that's not a real great threat. The IDS behind the firewall also fires off if anyone tricky enough tries to stealth scan me WITHOUT an initial SYN half scan or full scan (which would cut them off). Snort, behind the firewall, deals with the next layer of ankle bitters that are just a little cut above the common riff raff that try to port scan me. Snort makes for yet another good adjunct to both IPChains or NetFilter and PortSentry. The combination is awesome for frontend filtering and detection. Anyone getting through that without tripping an alarm is NOT an amateur and is worthy of my full, undivided, PERSONAL attention (and I have custom detectors and surprises for that level of "talent" as well). :-)=) BTW... Before anyone raises the customary remark about "What about denial of service attacks by spoofing Abacus PortSentry"... No one has documented an effective DoS attack against PortSentry in the field. It's just too difficult to do and too easy to protect against. My "evil twin" David LeBlanc (when he was still working with me at Internet Security Systems a couple of years ago) tried it against my PortSentry protected workstation. He failed. He knew everything I had on that system including the PortSentry configuration and never once managed to spoof so much as a single DoS attack that was effective. If he couldn't do it with his level of talent and his knowledge of my systems, it's going to take a world class talent who already knows my entire setup to make that happen. At that point, I have bigger problems than worrying about PortSentry (and it's also a tip-off from PortSentry that I need to be worried). It would take a lot of effort and a lot of incentive and a lot of access to make a real one happen. If you have all three of those, there are easier DoS attacks than attacking PortSentry. Lots of them that are LOTS easier. > > Yes it does. It's clearly stated in all the documentation > > on netfilter and in it's design. Read the fine manual (or web site) > > and you would have uncovered this (or been run over by it) for yourself. > > http://netfilter.filewatcher.org/ > Thanks. No problem. > -M Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: iptables: "stateful inspection?"
On Wed, Dec 20, 2000 at 11:18:10AM -0500, Michael Rothwell wrote:
> IPChains is essentially useless as a firewall due to its lack of
I think that's more than a little overstatement on your
part. It depends entirely on the application you intend to put
it to. It may be entirely useless TO YOU and your applications,
but your statement is far to broad to be accurate.
> stateful packet filering. Will the IPTables code in 2.4 maintain
> connection state?
Yes it does. It's clearly stated in all the documentation
on netfilter and in it's design. Read the fine manual (or web site)
and you would have uncovered this (or been run over by it) for yourself.
http://netfilter.filewatcher.org/
> -M
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: NTFS repair tools]
On Fri, Dec 08, 2000 at 03:34:09PM +0100, Jan-Benedict Glaw wrote: [...] > Maybe that can prevent pupils^H^H^H^H^Heople from shooting their > foots... Nothing can "prevent" them from shooting themselves in the foot, even taking away their guns and ammunition (removing it from the kernel) is rarely sufficient for the really skillfull and determined foot shooters (they want it, they'll patch it back in and complain about the inconvenience). We can make it more difficult and make sure they understand that it's a self inflicted injury when it happens to them, but we can not prevent it. Application Programmers Saying: "Software development is a race between software engineers who are attempting to create fool proof programs and the Universe which is attempting to create bigger and better fools." Software Engineers Saying: "So far, the Universe is winning." > MfG, JBG > > -- > Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! > /* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-177-5601720 */ > keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB > "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: NTFS repair tools]
On Thu, Dec 07, 2000 at 09:43:24PM -0700, Jeff V. Merkey wrote: > Peter Samuelson wrote: > > > > [Jeff Merkey] > > > Do folks not know this NTFS driver will trash hard drives? We need > > > to alert folks DO NOT USE WRITE NTFS MODE in those versions we know > > > are busted. > > Here's an idea: let's make r/w support a separate CONFIG option, and > > label it "DANGEROUS". > > Oh wait, we already do that. > > Perhaps we should warn users to back up their NTFS partitions before > > trying this option. Put that warning in the help text for > > CONFIG_NTFS_RW. > > Oh wait, we already do that too. > > How stupid does one have to be in order to enable an option labeled > > "DANGEROUS" for a non-experimental system? > Agree. We need to disable it, since folks do not read the docs > (obviously). Of course, we could leave it on, and I could start > charging money for these tools -- there's little doubt it would be a > lucrative business. Perhaps this is what I'll do if the numbers of > copies keeps growing. When it hits > 100 per week, it's taking a lot of > our time to support, so I will have to start charging for it. Huh? How disabled do you want it. It can't even be enabled unless you enabled experimental code options. Then, it's disabled by default and you first have to enable the R/O NTFS. Then you have to explicitly select the option to enable RW access that is clearly labeled DANGEROUS. This thing is not armed and dangerous due to an act of ommision. It's live and active only through three acts of commision. About the only thing left, short of removing it from the kernel entirely, is to make the option a hidden control option, like some of the debugging options, that requires editing a header file or a Makefile to enable. Is that what you are looking for? > Jeff > Jeff > > > > Peter Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New CD-R high capacity drive specs are coming. (fwd)
On Thu, Dec 07, 2000 at 12:33:35PM -0500, M Sweger wrote: > Hi, >See the article below. > I just read that the specs are out for three different types of CD-R > drives in terms of disk capacity and speeds from Constellation 3D,and it > is heading towards manufacturing. It's great for movies and coporate > archiving, but was degraded for the consumer market -- Nothing above > 5Gb/side for the consumer whereas for the coporate it's 200Gb/side. I > don't think it will compete for the PC market unless the disk capacities > are upped! Probably purposely degraded so that you can't copy a HDTV DVD > to your PC CD-R disk. Here is the > http://biz.yahoo.com/bw/001207/ny_constel.html">link Look at those specs closely and you may understand a little better. The "consumer" device is for the small 45mm discs (about the size of the credit card CD's or the little MO music discs). The CD sized (120mm) discs are the 32 Gig per side "VCR" devices. They've always said (first announcement well over a year ago) that they would focus first on the small disc r/w format for the consumer. My bet would be that the CD sized drives and the 32 Gig FMD discs would not be far behind. The 200Gig devices are a whopping 300mm! That's 2-1/2 the diameter of the current CD format. That's a 12" platter we are talking about here. That will be NICE for large centers with large data demands (kiss them tapes GOOD BY) but I don't see it on MY desk top! :-) So it's strictly a physical packaging and production issue. I can certainly see where they would want to roll that little 1.8" format out the door for the consumer market first. Lots of us would love to have the larger 5-1/2" format and I'm sure it won't be far behind, but you have to choose your initial devices carefully to avoid over burdening your startup production. I certainly wouldn't call it "degraded for the consumer market" any more than I would call those little MO discs "degraded for the consumer market". Those little discs are likely to be perfect for the consumer market (Radio Shack "pop a disc from your pocket into a player" crowd). That form factor would also be fantastic for PDAs, handhelds, and small laptops. I don't see any real conspiracy here, just some sensible business and production planning (gee, how refreshing). Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: About IP address
" "the whole notion of address classes becomes less important". IAC... Nowhere in RFC 1700 could I find any restriction on the use of addresses 128.0.*.*. It's simply been a convention and the network blocks in question have been taken out of circulation merely by assigning them to IANA as reserved. If you do a "whois [EMAIL PROTECTED]" you find that it is a network address reserved to IANA. It's a usable address, but its use is governed by who it is assigned to (like any other address block). Since IANA controls that address block, it's up to them to determine how it gets used. Also... "Assigned Numbers" didn't list network addresses, but "Internet Numbers" did. The last "Internet Numbers" was RFC 1166 which included definitions for all five classes (A B C D and E). D was the multicast block and E was reserved. This seems to be the last RFC defining these ranges and it places no restrictions on things like 128.0 or 191.255. There are some comments in both RFC 1700 and RFC 1166 about "Special Addresses" such as 0.0.0.37 where the network field is all zeros. That is defined as a host on the local network, but that's not relevant to this either. I have been unable to find any documentation in the RFCs which lay claim to restricting 128.0.*.* or 191.255.*.*. The fact that I did find the restrictions and definitions on 0.* and 127.* is telling me that the other restrictions probably were NOT codified in the RFCs or they would have been included in those appropriate sections of those RFCs. Both RFC 1700 and RFC 1166 refer to the special status of 0.* and 127.*. RFC 1700 makes no mention of network addresses 128.0 or 191.255. RFC 1166 lists them both as "reserved". They are restricted in use solely due to their assignment to IANA as reserved. I know of no reason why any software should take any special note of those addresses or do anything any different with them. At one time, I was involved in some heated discussions over my "Class B" (130.205/16) and whether the ".0" subnet (130.205.0/24) was legal. Answer is that under the "Class Subneting" scheme of things (Network / Subnetwork / Host), it is not, because subnets of 0 and -1 (notation for all ones) are reserved for the network address and broadcast. Under CIDR, however, they are perfectly legal. That may be where the origin of some of this confusion lies if you extrapolate that old "Class Subneting" restriction the other way into superneting (the precursor to CIDR). But the extrapolation is also wrong. > ;o) > -- > Mike A. Harris - Linux advocate - Open source advocate > This message is copyright 2000, all rights reserved. > Views expressed are my own, not necessarily shared by my employer. > -- > Looking for Linux software? http://freshmeat.net http://www.rpmfind.net > http://filewatcher.org http://www.coldstorage.org http://sourceforge.net Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: More modutils: It's probably worse.
Oh, I hate to add to a remark like that (OK, I lied, I love
trollbait...)
On Tue, Nov 14, 2000 at 11:20:35AM -0800, Ben Ford wrote:
> Olaf Kirch wrote:
> > sure request_module _does_not_ accept funky module names. Why allow
> > people to shoot themselves (and, by extension, all other Linux users
> > out there) in the foot?
> I thought that was the whole purpose of Unix/Linux?
True! Very true! Unix/Linux requires that the user shoot
themselves in the foot. Windows automates that process and does it
for the user, thus making foot shooting user friendly. :-)
> -b
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18Pre Lan Performance Rocks!
On Wed, Nov 01, 2000 at 12:07:50AM +, Alan Cox wrote: > > users must be fairly recent (4.x and about - 3.x has come into discussion > > but doesn't count here) customers. Obviously, they are big and SIGNIFICANT > > customers. Do we know that Linux can't handle the load, though, or is > > this just more supposition based on statistics? > On the same hardware netware 3 at least tended to beat us flat, but then it > wasnt a general purpose OS. I think what Jeff is trying to build is basically > a box that runs netware in the netware 3/4 style - ie fast and a little > unprotected with a standard linux application space protected mode on top of it > - its an interesting concept. Alan, I'll grant that what Jeff is attempting to do is laudable. It's just that I have experience with Netware 3.x and 4.x in the field (Ok... More 3.x than 4.x) and I have more than passing familiarity with 5.x security problems. I know he wants to achieve some of the good things that Novell managed. I know, from first hand experience, what cost some of those come at. Can he achieve the goal of matching the good while avoiding the bad? I hope so. He won't do it by promoting what he perceives as the advantages of Novell over Linux without at least some passing acknowledgement of the failures of Novell, the disadvantages, and the costs. I think his goals are good and his head is in the right spot, I just don't want to see history repeat itself. He has my best wishes, since both he and Linux will benefit. My $0.02. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18Pre Lan Performance Rocks!
On Tue, Oct 31, 2000 at 04:20:30PM -0700, Jeff V. Merkey wrote: > Nathan Paul Simons wrote: > > On Tue, Oct 31, 2000 at 03:38:00PM -0700, Jeff V. Merkey wrote: > > > It's makes more money in a week than Linux has ever made. > > The same could be said about Windows; that doesn't make it a > > technically superior solution. > > Speaking of Windows, a lot of your arguments are starting to sound > > more and more like arguments made a while back by a certain OS vendor from > > Seattle . . . > Not really. We ship Linux. I just want a Linux NetWare customers won't > laugh at when they try to put over 1000 people on it (which the NetWare > server was already handling we ate trying to replace). Oh! That's funny! Back in "the bad old days" Novell got laughed right off several campuses for this very reason. Why? Because Netware, at the time, could not handle more than 256 users on a given server. One admin I knew here at Georgia Tech reported on the expression on the face of the Novell presales support person when he was informed that the average public server had several thousand accounts. Netware customers that are worried about more than a few hundred users must be fairly recent (4.x and about - 3.x has come into discussion but doesn't count here) customers. Obviously, they are big and SIGNIFICANT customers. Do we know that Linux can't handle the load, though, or is this just more supposition based on statistics? > Jeff > > > > Wish not to seem, but to be, the best. > > -- Aeschylus > > > > -- > > Nathan Paul Simons, Junior Software Engineer for FSMLabs > > http://www.fsmlabs.com/ Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18Pre Lan Performance Rocks!
the quest for better
performance but comparisons to an inferior operating system which can pump
out packets faster than us is not the threat some people would like it to be.
My regards and respects to Jeff. He says he was responsible for the
Novell 4.x and 5.x systems. I note that he omitted the 3.x OS. Acknowledged
and respected! In my earlier days, I was the kernel jock responsible for a
proprietary version of XENIX and worked on Microport UNIX (may someone
forever drive a stake through that bastard's heart) and SCO Unix. I'm
"contaminated goods" for certain projects so I can't contribute to certain
applications like Taylor UUCP because I have legal source code to HDB UUCP
(as if UUCP means jack in today world). Does the current taylor UUCP have
the most possible efficient checksumming algorithm for the UUCP 'g' protocol?
No... No way... I've seen one that stomps Taylor UUCP's ass and takes names
from the AT&T SVR5 release 3.2 source tapes (took me a week to figure out just
how it worked - damn those comment strippers). Does it matter? Not one bit.
I want to see Linux excel. Does that mean that it has to beat
every benchmark set by an operating system that cut every corner that
would cause Linus to turn into a Quake Balrog? I think not.
> Jeff
> > Ingo
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[c.bailiff@E-SECURE.COM.AU: Re: IIS %c1%1c remote command execution]
This is being forwarded from BugTraq where there is an ongoing discussion over a security hole in IIS based on it's unicode decoder. This particular individual is stating that several unicode decoders, including the one in the Linux unicode_console driver, have failed to adhere to certain security warnings in some RFCs. This IMPLIES that there is a potential security problem in all of them. Anyone familiar with this who can comment on the problem in the Linux unicode_console driver? Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! -- Michael H. Warfield,| Voice: (678)443-6000 (678)443-6123 Senior Researcher - X-Force | Fax: (678)443-6477 Internet Security Systems, Inc. | E-Mail: [EMAIL PROTECTED] [EMAIL PROTECTED] 6600 Peachtree Dunwoody RD NE | http://www.iss.net/ 300 Embassy Row, Suite 500 | http://www.wittsend.com/mhw/ Atlanta, GA 30328 | PGP Key: 0xDF1DD471 - Forwarded message from Cris Bailiff <[EMAIL PROTECTED]> - Approved-By: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15-4mdk i686) X-Accept-Language: en Date: Thu, 19 Oct 2000 21:07:57 +1100 Reply-To: Cris Bailiff <[EMAIL PROTECTED]> From: Cris Bailiff <[EMAIL PROTECTED]> Subject: Re: IIS %c1%1c remote command execution To: [EMAIL PROTECTED] > Florian Weimer <[EMAIL PROTECTED]> writes: > > This is one of the vulnerabilities Bruce Schneier warned of in one of > the past CRYPTO-GRAM isssues. The problem isn't the wrong time of > path checking alone, but as well a poorly implemented UTF-8 decoder. > RFC 2279 explicitly says that overlong sequences such as 0xC0 0xAF are > invalid. As someone often involved in reviewing and improving other peoples web code, I have been citing the unicode security example from RFC2279 as one good reason why web programmers must enforce 'anything not explicitly is allowed is denied' almost since it was written. In commercial situations I have argued myself blue in the face that the equivalent of (perl speak) s!../!!g is not good enough to clean up filename form input parameters or other pathnames (in perl, ASP, PHP etc.). I always end up being proved right, but it takes a lot of effort. Should prove a bit easier from now on :-( > > It's a pity that a lot of UTF-8 decoders in free software fail such > tests as well, either by design or careless implementation. The warning in RFC 2279 hasn't been heeded by a single unicode decoder that I have ever tested, commercial or free, including the Solaris 2.6 system libraries, the Linux unicode_console driver, Netscape commuicator and now, obviously, IIS. Its unclear to me whether the IIS/NT unicode decoding is performed by a system wide library or if its custom to IIS - either way, it can potentially affect almost any unicode aware NT application. I have resisted upgrading various cgi and mod_perl based systems to perl5.6 because it has inbuilt (default?) unicode support, and I've no idea which applications or perl libraries might be affected. The problem is even harder than it looks - which sub-system, out of the http server, the perl (or ASP or PHP...) runtime, the standard C libraries and the kernel/OS can I expect to be performing the conversion? Which one will get it right? I think Bruce wildly understated the problem, and I've no idea how to put the brakes on the crash dive into a character encoding standard which seems to have no defined canonical encoding and no obvious way of performing deterministic comparisons. I suppose as a security professional I should be happy, looking forward to a booming business... Cris Bailiff [EMAIL PROTECTED] - End forwarded message - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
On Wed, Oct 18, 2000 at 12:12:39AM +0200, David Weinehall wrote: > On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote: > > On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote: > > > On Tue, 17 Oct 2000, Mikael Pettersson wrote: > > > Why Intel chose family 15 is still beyond me though. > > IV is 15 if you just translate the symbols, but ignore the meaning > > either that or someone was smoking alot of crack. > Huh? IV == 4. XV == 15. > I = 1, V = 5, X = 10, L = 50, C = 100, D = 500, M = 1000... He said if you just translate the symbols... He really sort of meant translate the digits (Roman Numeral Digits). i.e... IV => I V I V => 1 5 1 5 => 15. When I was at Michigan State University, we had something similar. The mainframe there was a CDC 6500, a 6000 series system, and the programing group called themselves the VIM group for "6000 series". That was VIM => VI M => 6 1000 => 6000. > Unless you translate the signs one by one. But that's not the correct > way to do it. In that case, Pentium III would have the modelcode > 0x0111... No it's not the correct way, but that's not the point, is it. > Then again, we all know that Intel has made processors in the past that > couldn't count, so I guess it's possible that they screwed up this time > too :^) No. They didn't screw up. They just tried a Roman Numeral pun. > /David > _ _ > // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ > // Project MCA Linux hacker// Dance across the winter sky // > \> http://www.acc.umu.se/~tao/http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Logitech USB Wingman Force Joystick...
On Mon, Sep 18, 2000 at 04:39:36PM -0400, Johannes Erdfelt wrote:
> Are you getting any oops'? I ran into a problem where with some devices,
> it would oops on open.
Nah... It turned out to be something REALLY obvious. I was
missing the joydev module. Someone else already pointed it out to me.
The module isn't sitting in the /lib/modules/.../kernel/drivers/char/joystick
directory with the joystick drivers, it's over in the .../input/ directory
where I missed it. :->
> JE
Thanks!
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Logitech USB Wingman Force Joystick...
Hello all... No joy with this joystick and I'm not sure what I'm doing wrong. I just received a Logitech USB Wingman Force Joystick. I have the iforce module compiled and loaded and the it recognizes the USB joystick. /var/log/message: Sep 18 15:09:32 alcove kernel: usb.c: USB new device connect, assigned device number 7 Sep 18 15:09:32 alcove kernel: input3: I-Force joystick/wheel on usb1:7.0 Sep 18 15:09:45 alcove kernel: usb.c: USB disconnect on device 7 Sep 18 15:10:28 alcove kernel: usb.c: USB new device connect, assigned device number 7 Sep 18 15:10:28 alcove kernel: input3: I-Force joystick/wheel on usb1:7.0 /proc/bus/usb/devices: T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c281 Rev= 1.00 S: Manufacturer=Logitech S: Product=Wingman Force C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=iforce E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl= 8ms E: Ad=01(O) Atr=03(Int.) MxPS= 32 Ivl= 4ms Trouble is "jstest /dev/js0" says no such device. My RedHat 6.2 system initially had the following js devices: c 15 0 js0 c 15 1 js1 c 15 2 js2 c 15 3 js3 I was also getting these errors in /var/log/messages: Sep 18 14:51:52 alcove modprobe: modprobe: Can't locate module char-major-15 The file linux/Documentation/joystick.txt says to use 13, 0-3, so I changed it to this: c 13 0 js0 c 13 1 js1 c 13 2 js2 c 13 3 js3 Still no go, but at least I'm not getting the modprobe errors now. My USB mouse on c 13, 63 is working like a charm. This is with kernel 2.4.0-test8 So, I assume that I'm still missing something obvious here. What? Any thoughts anyone? Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux
Andre,
On Sun, Sep 03, 2000 at 10:30:13PM -0700, Andre Hedrick wrote:
[...]
> WOOHOO, you remember Way to go Alan
> You and several others know that I stink at describing a complex point
> regardless that I understand it completely. I am just glad that you hung
> in there long enough for me to get the point across.
That's something that we are ALL guilty of! Understanding that
and realizing that, in ourselves and in others, is a mark of maturity.
[...]
> Cheers,
> Andre Hedrick
> The Linux ATA/IDE guy
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
