twistd make me a sandwich

The UNIX security model sucks.

Unfortunately, we are likely to be stuck with it for the next hundred quintillion years, it will outlive the sun and possibly humanity as we flee to other stars and trade our technology to species across the galaxy.  I understand this fact.  I can live with it.

Still, we must be able to do better than the current tools, like sudo.  I have had a variety of Twisted-based ideas for this kicking around in the back of my head for a while.

Imagine a Twisted daemon that ran at boot, seteuid and setegid to "nobody", but retaining root privileges.  spawnProcess already supports switching UIDs for your subprocess.  Instead of running subprocesses directly, you could run a Twisted client program which would connect to the root daemon and ask it to do something for you.

Such a daemon could be used for more than just 'sudo'.  Most of the tasks currently reserved for 'init', such as run-parts, could be run as "nobody" instead, with start-stop-daemon asking to run specific commands as root.  You could eliminate just about every "suid" binary by having all the binaries themselves be non-SUID, but distributed with security rules that allow their execution in specific restricted contexts.

Since security rules could be implemented in Python, it would be easy to have flexible policy declarations, like, "/usr/bin/foobar can always run /usr/sbin/bazqux processes as the 'foobar' user when run by people in the 'xyz' group".  This avoids giving unrestricted system access to either members of the 'xyz' group, or anyone who can exploit the 'foobar' executable.  Ideally programs could be distributed with their own security rules rather than, as sudo does, making separating privileges the administrator's responsibility.

Of course I have no time to implement this, nor to advocate it to the dozens of very high-profile projects which would need to adopt it in order for it to be useful.  I wish that I could, though, every time sudo lets me run two commands as root in a row because it would be too inconvenient to type my password a second time.

PyCon pwnd

From the PyCon feedback survey:

The Ghost(busters) in the Machine

How do you troubleshoot completely random problems?


My home desktop machine has been suffering from a Linux kernel "Oops" approximately once every two days for the last few weeks. I would really like it to stop doing that. When I get a stack trace in my logs, it's consistently in the "kswapd" process, even though I disabled all swap weeks ago.


I'm running Edgy on this machine, just like I was running it on my laptop and am running it on my work desktop. Those machines were both completely stable (modulo occasional ndiswrapper issues) running the exact same kernel.


It doesn't seem like it's a hardware issue. At least, the same machine has never exhibited any problems under Windows.


It isn't deterministically reproducible. It always seems to be in response to a click or some kind of user-input event during heavy disk I/O, but flogging the disks and mashing the keyboard, even for hours at a time, doesn't cause it to happen.


I am considering a fresh re-install to attempt a fix for this, but besides the inelegance of that solution, it seems likely that it will leave me in the same place.


Does anyone have a suggestion for tracking this down so that I'll actually know that it's fixed?

Grim Prophecy

You all thought I'd forget, didn't you?  About the dire consequences, that is?
  • Chrisopher has not responded yet.
  • Jonathan has not responded yet.  Jonathan has responded.
  • Travis has not responded yet.
  • Raffi has not responded yet, but the Synthesis blog seems to be offline, and it isn't really a personal thing anyway, so maybe I was out of line to tag him there.
  • Jason responded, but in a "friends only" post.  Kind of borderline, there, but he's doing the best so far (except Jonathan) so I'm not going to give him a hard time.
I'm just saying: it's not my fault that the cold hand of destiny will not brook a chain-letter dodger.

The Legend Continues

My saga of ndiswrapper on the macbook continues.


In fact, the dw102 drivers do cause crashes when associating with certain access points. Unfortunately the dw101 drivers don't work with certain (still other) access points, and the lenovo "abgn" drivers have some very peculiar problems with extremely bad UDP performance on the access points the dw101 don't work with.


It occurred to me after a few hours of trolling for better drivers that, in fact, there is a better way. Apple ships windows drivers specifically for this exact card! You don't need to use drivers for some other card with the same (or vaguely similar) chipset.


The Macintosh Drivers For Windows CD included with Boot Camp contains the driver. Obnoxiously, it's encapsulated within a MSI file, within an EXE installer, within a DMG image, inside the Boot Camp application. The only way I could discover to get at the wireless driver was to install the whole thing on a Real, Actual Windows Computer.


To access the driver CD if Boot Camp won't let you burn it, ctrl-click on "/Applications/Utilities/Boot Camp Assistant.app" and click on "Show Package Contents". Then, double-click on "Contents/Resources/DiskImage.dmg". Copy the files on the thing that shows up on your desktop onto a USB key or similar method of conveyance to a Windows machine, and run the installer.


Obnoxious as this process is, it thankfully doesn't make you install to a Windows installation on a Real Actual MacBook Core 2 Duo laptop. Any old Windows machine will do. The installer helpfully puts all the drivers into "C:\Program Files\Macintosh Drivers for Windows XP 1.1.2". The files for the network card are in the "net5416" folder.


Of course, they're also in a file called "net5416.tar.bz2" on my hard disk. I think Apple might take a dim view of me providing a public download site bereft of their unethical and legally dubious EULAs, but if you can't get at the drivers for some reason maybe I could let you have a copy.