So if that happened, then reality would eventually come to resemble Hollywood depictions -- where every agency or company is running their own custom OS...
Please, everybody knows that most people who work in Cheyenne mountain have a very quick commute from Colorado Springs. If not there's always on-base housing on sublevels 12-15 (sometimes even for civilians); senior staff and SG teams have quarters on sublevel 25.
Well, in theory UTF-8 shouldn't be vulnerable since the backslash is 128 and all UTF-8 encoded characters have the high bit set. So the backslash can't be part of a valid multibyte sequence. Whether it's an issue or not depends how PostgreSQL handles invalid UTF-8 sequences.
PostgreSQL defaults to SQL-ASCII encoding, which is unaffected by this particular attack. Only clients which connect using a multibyte encoding would be affected.
Actually, this really isn't a vulnerability in the database server itself -- the update just intentionally breaks certain badly written applications in order to protect them from themselves. If PHP's addslashes() ends up creating valid multibyte characters that produce unexpected behavior, that's really PHP's problem -- Postgres is just doing what it's told.
I see it a lot of times when a program's installer doesn't correctly register COM objects, and so the program tries to do it the first time it's run instead. AutoCAD is bad about that (as well as trying to re-associate its files all the time)
Do your users have Power user rights? The default reg permissions in XP allow power users to create new entries in the system-wide CLSID key. I see a lot of programs that work if you have power user but not standard user rights. Honestly I don't really see the point of power user since once you have that it's trivial to escalate to full admin.
The Oracle installer just sucks donkey balls though -- I repackaged all their stuff simply so I could install it under 'Program Files' where it belongs. It's hard to believe in this day and age that an installer would complain and not let you install in a directory with spaces in the name. Progra~1 works for the install but it gets really confused it you try to uninstall.
Maybe now they'll discover you can't run WindowsUpdate on an XP Pro SP2 machine without admin privileges, and fix it!
You really want regular users to be able to effect system-wide changes? (applying patches that may or may not break something, or might not even be from MS if somebody spoofed the windows update site)
You can come pretty close though -- with automatic updates there's a group-policy option that allows non-admin users to see and apply the updates.
You're better off not running Kodak easy share software at all. It's a major pig -- 3 or 4 services that run all the time, and 2 or 3 programs that run upon user logins == lots and lots of wasted memory / CPU cycles. It also has some shell extension crap that hooks into explorer and gums up the works.
A lot of times it requires registry permissions tweaks as well. Filemon/regmon are invaluable for that task.
A few of those (Oracle I'm looking at you) are so bad that I've gone so far as to chuck their installer completely and replace it with one of my own that sets appropriate permissions.
Even that's a band-aid, though. Programs really shouldn't be trying to store per-user data in a system-wide program folder. Not even counting the potential security hole, it's a pain if users can't change settings without affecting other users of the same computer.
That's just because oracle writes some of the most retarded software ever. Come on, it's 2006 and they still haven't figured out how to deal with spaces in directory names? Or to actually register COM objects correctly during the install rather than try to do it every time you start up the program (ADI is really bad about this). How about the fact that you need an astonishingly bloated software install just to talk to their database at all?
That's just on Win32. Don't even get me started about requiring X/Java for installs on their unix stuff.
Oracle is definitely one of the companies that's responsible for the mess the windows world is in. It's a major pain to get their crap working under non-admin accounts.
After the tests, representatives of Fedora, Linspire and Novell told me that Sony Vaios are known to have compatibility problems with Linux.
Let me fix that for you: Sony Vaios are known to have compatibility problems with Windows.
Seriously, if you've ever installed stock 2k or XP on a sony (especially a laptop) then you know what I mean. 10 "Unknown Device" entries that need drivers you're lucky if you can find on their web site. Drivers that all depend on some "Sony I/O controller" and "Sony management software" you have to find somewhere. Then half of them won't install, cryptically complaining "wrong model number", even though the one you downloaded is exactly what it says on the case. Oh, and the joy of function keys that won't work pretty much ever, because they're software based and the program for it isn't downloadable.
Your only other choice is to use the Sony-provided "Restore CD" that installs all sorts of OEM garbage you can never fully get rid of.
False sense of security. A firewall may prevent incoming connections from random parts of the internet, but will do nothing to protect clients from each other. Since the network is unencrypted, anyone in range can hop on and hack away (or better yet just sniff the packets).
Security really needs to be enforced on the individual clients -- there's just too many unknowns to try to do it at the network level. After all, the Internet is based on the idea of a "dumb" network and "smart" hosts.
Only by causing a blocking call can you make sure that before the thread can run again, that the buffer is no longer used by the kernel.
This is stupid. Applications that need to handle hundreads of thousands of clients simply don't block.
I completely missed the irony of this comment the first time around... The vmsplice() approach that Linus is talking about is exactly that -- a call that will block until the kernel is done with the previous buffer.
Except that there's no API call that detects whether or not the buffer can be reused.
If there was, it would be non-portable and applications would then have to double their complexity to conditionally use it. With COW, zero-copy is an option you turn on once and the app doesn't have to worry about it.
If the app is using a suitably large ring-buffer, the kernel will usually be done transmitting before it gets reused. A copy won't happen unless the NIC can't keep up, or the remote machine isn't ACKing fast enough. In that case you need to back off your transmit rate anyway, so the bottleneck isn't the extra page faults. Think of it as a self-adjusting algorithm.
This is simply a case of the erroneous idea that the application can do a better job than the OS in deciding how to manage buffers and trying to micro-manage it.
This is stupid. Applications that need to handle hundreads of thousands of clients simply don't block.
Nobody is saying they have to block. The app doesn't absolutely HAVE to avoid the COW overhead at all costs. If it just uses a buffer bigger than the 2x the TCP window, 99% of the time no copy is necessary, without a big mess of code complexity.
But being as how there isn't such a call, why CoW the kernel buffer anyway?
To catch the 1% of the time that it needs to be copied, without imposing a huge burden on application writers.
Updating those page tables is slow, and doesn't buy very much- except that it makes the naive approach get written in the first place.
Anyone who wants to write a naive application is free to not enable zero-copy at all, and simply use write(). The normal overhead of copying buffers isn't terribly bad on modern hardware -- only extremely high-performance apps need zero-copy in the first place.
I would just prefer that their response is to release a stable system using their method.
No need -- such a system is already out there and in wide usage.
As opposed to some obscure method using an non-portable interface (vmsplice) that's not even in the kernel version most people use for production servers.
However, given that the "free()" routine is part of the OS in FreeBSD
No, it's not unfortunately. It's a library call that mucks up [s]brk() or munmap().
In *BSD, libc is considered part of the OS. There are a lot of interfaces that are used between libc and the kernel which aren't meant for general consumption (the threading system calls for instance).
Slashdot Mirror
Which is kind of funny, because having dealt with both SBC and pre-buyout AT&T, I always had worse experiences with AT&T than SBC.
Sure, SBC sucked. But AT&T sucked more.
As far as I'm concerned, the name change was a bad move on the part of their marketing department.
Does Vonage encrypt their traffic?
There's a good chance that your Internet traffic gets routed over an AT&T-controlled network at some point...
Yeah, but that's on a terraformed planet with loads of dirt and germs and trees that look just like the woods around Vancouver.
That's Druish, not Jewish!
3.2%?! No wonder so many Oklahoma students have suicide plans.
Interesting that by wording the bill that way, that means that they're recognizing a class of "appropriate violence". I wonder how that's defined...
So if that happened, then reality would eventually come to resemble Hollywood depictions -- where every agency or company is running their own custom OS...
If his employer is at Cheyenne mountain
Please, everybody knows that most people who work in Cheyenne mountain have a very quick commute from Colorado Springs. If not there's always on-base housing on sublevels 12-15 (sometimes even for civilians); senior staff and SG teams have quarters on sublevel 25.
Bah, stupid pseudo-html. Backslash is < 128 (0x5c)
Well, in theory UTF-8 shouldn't be vulnerable since the backslash is 128 and all UTF-8 encoded characters have the high bit set. So the backslash can't be part of a valid multibyte sequence. Whether it's an issue or not depends how PostgreSQL handles invalid UTF-8 sequences.
PostgreSQL defaults to SQL-ASCII encoding, which is unaffected by this particular attack. Only clients which connect using a multibyte encoding would be affected.
Actually, this really isn't a vulnerability in the database server itself -- the update just intentionally breaks certain badly written applications in order to protect them from themselves. If PHP's addslashes() ends up creating valid multibyte characters that produce unexpected behavior, that's really PHP's problem -- Postgres is just doing what it's told.
I see it a lot of times when a program's installer doesn't correctly register COM objects, and so the program tries to do it the first time it's run instead. AutoCAD is bad about that (as well as trying to re-associate its files all the time)
Do your users have Power user rights? The default reg permissions in XP allow power users to create new entries in the system-wide CLSID key. I see a lot of programs that work if you have power user but not standard user rights. Honestly I don't really see the point of power user since once you have that it's trivial to escalate to full admin.
The Oracle installer just sucks donkey balls though -- I repackaged all their stuff simply so I could install it under 'Program Files' where it belongs. It's hard to believe in this day and age that an installer would complain and not let you install in a directory with spaces in the name. Progra~1 works for the install but it gets really confused it you try to uninstall.
Maybe now they'll discover you can't run WindowsUpdate on an XP Pro SP2 machine without admin privileges, and fix it!
You really want regular users to be able to effect system-wide changes? (applying patches that may or may not break something, or might not even be from MS if somebody spoofed the windows update site)
You can come pretty close though -- with automatic updates there's a group-policy option that allows non-admin users to see and apply the updates.
You're better off not running Kodak easy share software at all. It's a major pig -- 3 or 4 services that run all the time, and 2 or 3 programs that run upon user logins == lots and lots of wasted memory / CPU cycles. It also has some shell extension crap that hooks into explorer and gums up the works.
A lot of times it requires registry permissions tweaks as well. Filemon/regmon are invaluable for that task.
A few of those (Oracle I'm looking at you) are so bad that I've gone so far as to chuck their installer completely and replace it with one of my own that sets appropriate permissions.
Even that's a band-aid, though. Programs really shouldn't be trying to store per-user data in a system-wide program folder. Not even counting the potential security hole, it's a pain if users can't change settings without affecting other users of the same computer.
That's just because oracle writes some of the most retarded software ever. Come on, it's 2006 and they still haven't figured out how to deal with spaces in directory names? Or to actually register COM objects correctly during the install rather than try to do it every time you start up the program (ADI is really bad about this). How about the fact that you need an astonishingly bloated software install just to talk to their database at all?
That's just on Win32. Don't even get me started about requiring X/Java for installs on their unix stuff.
Oracle is definitely one of the companies that's responsible for the mess the windows world is in. It's a major pain to get their crap working under non-admin accounts.
After the tests, representatives of Fedora, Linspire and Novell told me that Sony Vaios are known to have compatibility problems with Linux.
Let me fix that for you: Sony Vaios are known to have compatibility problems with Windows.
Seriously, if you've ever installed stock 2k or XP on a sony (especially a laptop) then you know what I mean. 10 "Unknown Device" entries that need drivers you're lucky if you can find on their web site. Drivers that all depend on some "Sony I/O controller" and "Sony management software" you have to find somewhere. Then half of them won't install, cryptically complaining "wrong model number", even though the one you downloaded is exactly what it says on the case. Oh, and the joy of function keys that won't work pretty much ever, because they're software based and the program for it isn't downloadable.
Your only other choice is to use the Sony-provided "Restore CD" that installs all sorts of OEM garbage you can never fully get rid of.
I told you never to call me on this wall!
This is an unlisted wall!
False sense of security. A firewall may prevent incoming connections from random parts of the internet, but will do nothing to protect clients from each other. Since the network is unencrypted, anyone in range can hop on and hack away (or better yet just sniff the packets).
Security really needs to be enforced on the individual clients -- there's just too many unknowns to try to do it at the network level. After all, the Internet is based on the idea of a "dumb" network and "smart" hosts.
Everything I touch(1), I ~#
Looks like the interface has changed already.
Look at Linus's post yesterday and you'll see that in his idea of how it would be used he specifically mentioned blocking.
Only by causing a blocking call can you make sure that before the thread can run again, that the buffer is no longer used by the kernel.
This is stupid. Applications that need to handle hundreads of thousands of clients simply don't block.
I completely missed the irony of this comment the first time around... The vmsplice() approach that Linus is talking about is exactly that -- a call that will block until the kernel is done with the previous buffer.
Except that there's no API call that detects whether or not the buffer can be reused.
If there was, it would be non-portable and applications would then have to double their complexity to conditionally use it. With COW, zero-copy is an option you turn on once and the app doesn't have to worry about it.
If the app is using a suitably large ring-buffer, the kernel will usually be done transmitting before it gets reused. A copy won't happen unless the NIC can't keep up, or the remote machine isn't ACKing fast enough. In that case you need to back off your transmit rate anyway, so the bottleneck isn't the extra page faults. Think of it as a self-adjusting algorithm.
This is simply a case of the erroneous idea that the application can do a better job than the OS in deciding how to manage buffers and trying to micro-manage it.
This is stupid. Applications that need to handle hundreads of thousands of clients simply don't block.
Nobody is saying they have to block. The app doesn't absolutely HAVE to avoid the COW overhead at all costs. If it just uses a buffer bigger than the 2x the TCP window, 99% of the time no copy is necessary, without a big mess of code complexity.
But being as how there isn't such a call, why CoW the kernel buffer anyway?
To catch the 1% of the time that it needs to be copied, without imposing a huge burden on application writers.
Updating those page tables is slow, and doesn't buy very much- except that it makes the naive approach get written in the first place.
Anyone who wants to write a naive application is free to not enable zero-copy at all, and simply use write(). The normal overhead of copying buffers isn't terribly bad on modern hardware -- only extremely high-performance apps need zero-copy in the first place.
I would just prefer that their response is to release a stable system using their method.
No need -- such a system is already out there and in wide usage.
As opposed to some obscure method using an non-portable interface (vmsplice) that's not even in the kernel version most people use for production servers.
No, it's not unfortunately. It's a library call that mucks up [s]brk() or munmap().
In *BSD, libc is considered part of the OS. There are a lot of interfaces that are used between libc and the kernel which aren't meant for general consumption (the threading system calls for instance).