Agreed, mod the 'three' guy up, it's the biggest laugh I've had out of this comment thread so far (and that IS saying something given all the other giggling, chuckling, guffawing and other outbursts I've uttered whilst reading it).

From a long experience with various SSRIs, an nSRI, an anti-psychotic and a beta blocker (and now an anti-convulsant with alleged action against anxiety, but it's too soon to draw conclusions on that one yet) I can tell you that the coin can also land on its edge, i.e. the medication does sweet fuck all other than a few side effects at the start and possible withdrawal symptoms if you come off it too quickly (thanks Venlafaxine for that lovely 'rollercoaster' effect).

And there's also another thing that confused me. There I was, following your advice, and looking at the sections I could tweak in this way... and wondering WTF the 'Contact Info' one was. It took me 5 minutes to notice the additional 'tab' near the top of the screen. Bad UI design.

But, still, even if you lock down every section to 'only some friends' using groups and/or specific friend names, all it takes is *ONE* person you've decided is trustworthy to have a moment of insanity and run an app that trawls all possible info it has access to. That or their off-spring, significant other, pet, random friend visiting etc. decides to fill in some quiz a (non-trusted for this purpose) friend had done, visible in your feed, and it's all blown out of the water again.

What is needed is a Facebook option to say "Even if I've given access to some of my profile information to someone, when they use a Facebook Application the most that Application knows about me is that a) I AM their friend, b) plus any information I have explicitly already allowed that Application to access, or c) Anything I've made available to Everyone on Facebook".

In essence it seems that Applications get sudo rights to the person using them.

Just having mmap_min_addr and setting it to a page or more above 0 isn't good enough. It also depends very much on the exact kernel version you're running. 2.6.30.2 had a problem with both SELinux and personalities making it possible to get around this. 2.6.30.3 fixed both I believe.

See http://lwn.net/Articles/342420/ for more about which versions are vulnerable and why (and, yes, I'm the same Athanasius linked to in the "This change is not enough for some users, who have requested the ability to turn off the personality feature altogether. " bit, if I could get my arse more in gear I'd have coded up a sysctl/personality patch by now).

Back in the very early days of Battlefield 1942's PC release myself and friends would waste hours doing silly things like climbing a hill, setting up explosives, and seeing who could get themselves closest to a point below.

That and landing a plane on the back of a destroyer: http://www.miggy.org/games/bf1942/pics/utini-plane-dd-back.jpg

Or on a landing craft: http://www.miggy.org/games/bf1942/pics/utini-landed-on-landing-craft-2.jpg

Or a hut: http://www.miggy.org/games/bf1942/pics/utini-plane-on-hut-2.jpg

And then there was wing walking: http://www.miggy.org/games/bf1942/pics/athan-pilot-cptdoom-wing-bridge-1.jpg (there's a sequence up to -10 there)

And of course there was a whole community focused on making videos of stunts in the game.

Indeed, my reading of the whole thing was that the Linus/Alan problem can be summed up by:

1) Linus being concerned only with fixing the reported regression even though this still left other nasty bugs in the code.

2) Alan trying to fix those other things as well.

So when Linus took Alan to task for trying to fix other things as well Alan took it as criticism of the whole patch and it took a while for them both to realise where the other was coming from (Linus has since said he'll accept patches for the other changes in post-2.6.31 release time, not now we're in the 2.6.31-rc4 phase).

This ought to be crashing at the sk = tun->sk line, because the structure is smaller than a page, and page 0 is mapped no-access (I assume Linux does this; it's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing).

If you actually read the exploit code (see: http://grsecurity.net/~spender/cheddar_bay.tgz) the thing that really enables this exploit is one of two ways to map page zero. One of these seems to be a flaw with SELinux (either with the default settings and/or how the default config commonly ships) or using personality(2) to select a personality that explicitly allows this.

From the exploit for the personality case:

int main(void)
{
        int ret;
        struct stat fstat;
 
        ret = personality(PER_SVR4);
 
        if (ret == -1) {
                fprintf(stderr, "Unable to set personality!\n");
                return 0;
        }

Note you do need some setuid root program even with this (from my reading of the exploit code).

In the SELinux case "it just works" without needing the setuid program it seems.