The UK implimentation of the EU copyright directive (read: UK-DMCA) has been published. The fight continues. Here's NTK's summary:
when this becomes law, the "contract" you have with a copyright holder will almost completely trump your right as a purchaser of copyrighted material. And your contract is hereby defined by the copy protection technologies the distributors stick on your media. So if that CD doesn't play on your PC - well, that's what you "agreed" to, and there's nothing you can do. If you try and circumvent any the copy protection (or, in the case of computer programs, explain how to do so to anyone else), you can be punished as much as if you were pirating the data yourself (Article 6). Heck, if you even try to remove any of the tracking spyware, you'll be in equal amounts of trouble (Article 7).
Is anyone organising the defence? Time for another letter to my MP I guess
All the security problems in 2.4.18 are listed in the 2.4.19-sec notes. however, if you're in the US the DMCA means it cannot be published there [FAQ]. For non-US citizens you can get it here. Of course, all this moral high ground is about to collaspe under the weight of the UK-DMCA.
- EWD594 - Th worlds first competent programmer
- Really dumb thief in my local town
- The SysAdmin card game [via Aaron]
The Labour Party (who currently hold power in the UK for a second term, after the biggest second term election victory ever) have dire fiscal problems. They are estimated to be £6-8 million in debt and have had to ask for a donation of £100,000 from the unions to cover short term costs.
The unions obliged and are making no secret of the fact that they expect something in return in terms of policy decisions.
Am I the only one whos jaw dropped at the way this corruption (and that's what it is) is accepted? If a business did the same there would be political hell to pay. It's time for public funding of political parties.
(and maybe then the MP3 party can have a good stab )
chroot(2) requires root on most systems, therefore it must be run before setuidgid. This means that setuidgid is run with root permissions (as it always must be) and must be in the chroot jail in order for chroot(1) to run it. Thus if the final process in the chain (usually the one that setuidgid execs) is exploited it can change the setuidgid binary in the jail, and so runcode as root the next time that daemon is started.