| < | May 2008 | |||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
For most of April, I've been on the road. Late night rides all around town, through inner ring road and cubbon, chugging along on my new bike. The weather's been brilliant and I was out, just cruising along the roads, like in a dream.
Yup, I went and splurged on a brand spanking new Royal Enfield Thunderbird. Full 350 cc, 18 BHP of raw petrol power, purring along like a kitten at full throttle, but whisper quiet in idle. For such a heavy bike, it is surprisingly easy to handle, taking bottom heavy curves on turns and excellent stability at speeds. The bike's behaved pretty well so far, the first full tank of petrol lasted me for around 600 Kms. And for once, I'm actually riding a bike made for someone six feet plus. In short, I love it.
The nights are long and the roads are empty
The world's sleeping and
nobody's watching
And the wind whispered to me; keep on driving.
There's a certain cultural bankruptcy which shows itself in sequels. It indicates, that you're reduced to imitating yourself. But this isn't that kind of a sequel. No, not the kind where there are T Rexes in the city, trying to make a living drawing cartoons or Arnie switching from ammo boxes to ballots. This is the kind which gives a New Hope.
Yesterday, I had an outpouring of hate against the linux capability model. But the problem turned out to be that setuid resets all the capabilites. In hindsight that makes a lot of sense, but didn't even strike until the kernel people (y! has those too) got involved (and I didn't RTFM).
Enter Prctl: The solution was to use the prctl() call with PR_SET_KEEPCAPS to ensure that the capabilities are not discarded when the effective user-id of a process is changed. But, even then, only the CAP_PERMITTED flags are retained and the CAP_EFFECTIVE are masked to zeros.
So, with the prctl call and another cap_set_proc to reset CAP_EFFECTIVE, it was on a roll. Here's the patch on top of unnice.c.
#include <sys/resource.h>
+#include <sys/prctl.h>;
@@ -26,12 +27,14 @@
if(!fork())
{
+ prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0);
/* child */
if(setuid(nobody_uid) < 0)
{
perror("setuid");
}
+ cap_set_proc(lcap);
if(setpriority(PRIO_PROCESS, 0, getpriority(PRIO_PROCESS, 0) - 1) < 0)
Thus concludes this adventure and hope that this blog entry serves as warning of things to come. Watch this space for more Tales! Of! INTEREST!.
--Running infinte loops is a tricky challenge. What happens to a process when a programmer writes an infinite loop, should be familiar to all. But the challenge is to not let that affect the *other* processes. There seemed to be a perfect solution to it - setrlimit().
The function lets you set soft and hard limits on CPU, so that if a process does exceed the soft limit CPU usage, a SIGXCPU is raised. The process can catch the signal and do something sensible. Basically, all that was required was for the process to call setpriority and let the linux process scheduler slow it down to a trickle.
But a process can lower its priority, but not raise it - if it is a non-privileged process. But linux capabilities allows you to grant CAP_SYS_NICE to the process which essentially lets a non-privileged process muck around with priority - down and up.
To begin with /proc/sys/kernel/cap-bound is unbelievably confusing to use. It is a 32 wide bit-mask on which the 23rd bit apparently seems to be the CAP_SYS_NICE value. After much mucking around, I came to the conclusion that "-257" would be 0xFFFFFEFF which only disables CAP_SETPCAP. But even then the setpriority call kept failing. Here's my test code.
cap_t lcap;
const unsigned cap_size = 1;
cap_value_t cap_list[] = {CAP_SYS_NICE};
lcap=cap_get_proc();
cap_set_flag(lcap, CAP_EFFECTIVE, cap_size, cap_list, CAP_SET);
cap_set_flag(lcap, CAP_PERMITTED, cap_size, cap_list, CAP_SET);
cap_set_proc(lcap);
if(setuid(nobody_uid) < 0)
perror("setuid");
if(setpriority(PRIO_PROCESS, 0, getpriority(PRIO_PROCESS, 0) - 1) < 0)
perror("setpriority");
Here's a link to the test case in a more compileable condition. Build it with gcc -lcap and run with sudo to test it. Right now, my ubuntu (2.6.22) errors out with this message.
bash$ gcc -lcap -o unnice unnice.c bash$ sudo ./unnice 0: =ep cap_setpcap-ep setpriority: Permission denied
The core issue has to do with apache child-process lifetimes. The only recourse for me is to kill the errant process after the bad infinite loop and have the parent process spawn a new process with a normal priority. But which means blowing off nearly all the local process cache, causing memory churn and more than that, the annoyance of a documented feature not working.
This story currently has no ending, but if any kernel hackers are reading this and should happen to know an answer, please email gopalv shift+2 php noshift+> net. And thus we prepare for a sequel (hopefully).
--Flaws are inherent in the makings of a hero. For a perfect canditate for heroic tasks would be a man made out of stone - cruel, rational and unemotional. But only cruel to be kind, rational to the core and unstirred by emotional pulls. But who would want to call him a hero?
Over the last two days, I slowly trawled my way through the twelve issue paperback of Watchmen. It has proven to be an interesting comic to peruse.
The book is a continous dismantling of the word "hero". More appropriately, of the super-hero genre - the take-no-lives, nobody-got-hurt-but-the-criminals world of the original heroes. But having accepted collateral damage as a way of life, for the super hero, the question remains - how far will you go to save humanity?.
For your own good: More interesting is the dissection of the purpose of authority. The question hangs in the air - "Who are we protecting them from?". And only the comedian dares answer, but with mirth - "From themselves". Is a nice concept, that few will suffer for the good of many. But that line having been crossed, decisions get mired in a subjective quagmire of the value of a life against another. And it evades the other question - what happens to those who dispense with justice?
quis custodiet ipsos custodes: Ah, but who will watch the watchmen. And even if benevolent they be, what if they take the path piled with corpses. The entire book is a critque on the hypocrisy of authority, the few who are not accountable to any. After all, as I've noticed, in a fair world intentions do not matter.
The book leaves you doubtful how to interpret the shades of grey in people. But at least that's why Rorschach has only black or white - never any gray, on his face. Perhaps to him, it's all black'nwhite.
Perhaps, the real hero is a monster who's cruel to be kind. Amen.
--It's a very liberating sensation. But for those who have become accustomed to seeing me with long and curly hair, this must come as a shock. The summer was getting to me and my other reasons to keep my hair uncut have long since disappeared. And so has my hair.
After having survived countless threats by several (near & dear to me) to have it cut during my sleep, my current crop of hair has been reaped. I've come to realize how much of a hassle it had been. Except for the bright April sun beating down on my head or the newly acquired intimate knowledge of A/C vent locations in office, everything else seems to be going according to plan.
And after all, it'll grow back. It's not like this is the first time I've doen this.
--Conflict is the essence of drama. Conflict between people is easy enough to construct - the villain, the hero and the heroine. Put a face on each and the characters play themselves out. Evil shall rule, but it shall be short-lived. Good shall win at the end and order shall be restored.
But occasionally something comes along which distills drama out of nothing but circumstances. No evil, merely ordinary people, their thoughts and cognitive dissonances echoing off each other. That's how I felt at the end of watching Juno.
Unlike other movies I write about, I have no spoilers for this one. But the soundtrack haunts me. Definitely something to go back and listen to - not just for the melody, but for the lyrics.
You're such a good friend I haveta break your heart. Tell you that I love you then tear your world apart.
Listen - and hum along ... ~~ you're a part time lover and a full time friend ~~.
--In response to CVE-2008-1488, APC 3.0.17 has just been pushed out with the requisite security fixes. But in the process of producing a php4 compatible release, a significant amount of code has been reverted in the merge into an APC_3_0 branch for future bugfixes.
I've spent a couple of hours unmerging my "bye bye php4" cleanups with the help of Kompare. And my sanity is simply due to the fact that I can "cvs diff -u | kompare -" to look at the resulting huge patch. But it is not unpossible that the new code merged from HEAD has regressions, so you could also apply the unofficial patch onto 3.0.16.
--I'm sorry, I just received a late update (at great cost) from Anthony Baxter.
The last keynote from Linux.conf.au was about the upcoming Python "We'll break all your code" 3k. Perhaps not quite keynote material, but it covered a gamut of issues which will break old code when the move happens - and he did work for a colorful company. The set & dict comprehensions, function annotations and dictionary views are probably worth the terrible loss of reduce(), my favourite companion to map(). And obviously old style classes & string exceptions were excess fat to be trimmed anyway. But there was more interesting code to test.
>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance >> import this
And check the output twice.
--posted at: 04:13 | path: /conferences | permalink |
I was there, but I didn't talk. Didn't sit around either.
Yes... I stood behind people.
And then, I came back. With a somewhat odd feeling at the back of my mind. Somehow, unlike all the other years, this year it felt more like a JNU event, rather than an ILUG-D event. What with the focus shifting off software into the rather vague (for me) realms of freedom. Maybe it was the conclave or the dinners, it didn't scream out ILUG-D like it used to - but that may not be a bad thing, per se.
Shall just have to wait and watch.
--posted at: 03:13 | path: /conferences | permalink |
Occasionally, I do wonder why I do what I do, especially with software. The answers I've got with might not make sense to everyone - actually, it no longer makes too much sense to *me* today. But one thing's remained the same - it wasn't the money then and it isn't money now.
Everyone admits that more money helps (talks, walks you home and even buys you dinner). But the question at hand was whether money, more accurately, the presence thereof, hurts open source projects. And Stormy Peters began with that question, into her LCA '08 keynote.
The internal motivations to write F/OSS usually are weakened when there's greenbacks flying. Not to mention money brings in the people who herd it, from the clan of MBA (not to be confused with N.W.A). The processes and rest of the beasts of communication, reports and roadmaps which follow aren't necessarily bad, but they aren't "fun". But even when hacking hasn't been instutionalized, money is a selective reward, which splits the community into those who are paid and the rest. Dunc-Tanc is a classic example of this divide in action. And I'd personally lost that rush the moment I start equating efforts to money - there's a stress level which you can't pay me to take up, but in which I used to live day in & day out.
Stormy Peters takes on the topic from the point of view of someone actively involved in funding open source projects & developers. Occasionally, I run into clearer insights than mine, but conclusions I gathered from the talk are something to a closer look at.
Once a f/oss developer, always a f/oss dev. Even when you've gotten off the rush for some project, pushing it along as a good engineer, the hacker in you doesn't sit around. So, even if you don't do the same for free, it's very likely you'll do something else for the same reasons you did it first - look at the ex-Eazel folks. Anyway, history might just rhyme or pun, or maybe people just go do the same again ( *cough* Gnome Online Desktop), but whatever they already did - is not lost.
Anyway, to the objective reader, I'd suggest that you ignore my blatant bias in the above post and go watch the video.
--posted at: 21:54 | path: /conferences | permalink |
In the last three years, very few things have stayed the same for me. Hardly did I think when I walked into my cube in Feb 2005, that I'd still be sitting in the same exact cube when 2008 dawned. My team changed, my entire upward hierarchy changed, even the company name changed - but hidden behind the walls of 3A-14 I sat. Slept there, ate there and sometimes even did some work.
I've come a long way in those three years, but I hardly moved at all. But perhaps this world did move a lot and all's relative.
--After all the dust from the miniconfs settled down, the real conference began with a real treat - Bruce Schneier talking on Reconceptualizing Security [video (~150 MB)]. The keynote was about dealing with security as an intangible feeling as well as the reality of security.
Lemons: But before I head off into what that talk was about, let me introduce a new concept - Market for Lemons. The idea is that when the quality of a product (like a used car) cannot be assessed easily, the bad car (i.e a lemon) would sell for a profit, while the good car wouldn't have any customers because it is expensive. The scenario is exactly tilted towards the dishonest seller, in the absence of proper information and/or blacklists for lemon peddlers.
The security software market right now is such a one (I'd say that the job market is too). Products which are pure snakeoil are completely indistinguishable from real products from a brochure or presentation. As was clearly illustrated today. The company which invests more efforts in creating the illusion of security would potentially win over someone who has been actually spending time & effort to secure their product. The price war cannot be fought between good & bad without enough in-depth information about stuff under-the-hood.
There is probably a sweet spot between real security and the illusion of security, which would be profitable. It wouldn't be bullet-proof security by any stretch of imagination, but the sense of security wouldn't necessarily be misplaced. Which is what the profit-oriented capitalist economy would gravitate to, provided there was enough awareness & information about what is actually in the box.
Q&A: I actually got to ask Bruce Schneier a question - about the meta-stable state of this balance, where every new development/marketing tactic would again upset the market off this point. He admitted that it was an interesting question, but suggested that it would probably dampen into insignificance (think about soaps & detergent brands).
Anyway, there I was, communicating to Bruce Schneier without encyrption.
--posted at: 20:13 | path: /conferences | permalink |
Looks like I'll be able to make it to freed.in. Except, in a departure from the usual, I'll not be presenting there. I wasn't online or in any state to prepare a decent proposal for the conference. I'll be attending it as a vanilla delegate to the conference, possibly talking about something during the conclaves.
I wouldn't miss it if I were you (even if I were me, which I am).
--posted at: 23:42 | path: /conferences | permalink |
DHCP makes for bad routing. My original problems with DHCP (i.e name resolution) has been solved by nss-mdns, completely replacing my hacky dns server - ssh'ing into hostname.local names work just fine.
But sadly, my WiFi router does not understand mdns hostnames. Setting up a tunnel into my desktop at home, so that I could access it from office (or australia for that matter), becomes nearly impossible with DHCP changing around the IP for the host.
UPnP: Enter UPnP, which has a feature called NAT Traversal. The nat traversal allows for opening up arbitrary ports dynamically, without any authentication whatsoever. Unfortunately, there doesn't seem to be any easily usable client I could use to send UPnP requests. But nothing stops me from brute-hacking a nat b0rker in raw sockets. And for my Linksys, this is how my POST data looks like.
<?xml version="1.0" ?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s=
"http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost/>
<NewExternalPort>2200</NewExternalPort>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>22</NewInternalPort>
<NewInternalClient>192.168.1.2</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription>SSH Tunnel</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping>
</s:Body>
</s:Envelope>
And here's the quick script which sends off that request to the router.
--Monday: I had this illusion that I had no jet lag after reaching melbourne. So, I headed out to the security miniconf. The WiFi wasn't up yet (it never is for the first day). The couple of talks I was really focussing on was the OpenSSH one and the 'aggressive' Network defense one.
The latter talk had some interesting 'facts' about ICMP. The ICMP host redirect used in the sense of "talk to the hand" packet dumping. Also suggestions for an ICMP quench message to be un-deprecated as well as a lot of ire directed at sysadmins who just drop ICMP at fire-walls.
The OpenSSH talk had a fair amount of detail about writing secure code and more importantly retro-fitting security into existing code. Ironically, it began by quoting a Microsoft research paper as inspiration for a lot of work. Moving on, it shows how different is sshd compared to the standard unix daemon. Rather than move ahead accept-fork model followed very successfully by apache, sshd uses accept-fork-exec to run a master and slave process. The master handles all the higher privilege functions while the latter handles the protocol/crypto/book-keeping functionality.
Tuesday: I slept off till late afternoon. Woke up in time to peek into the gaming miniconf and walk around between Lygon st. & Swanston st.
Still not adjusted to local time yet, but the extra coffee seems to be helping today.
--posted at: 12:13 | path: /conferences | permalink |
And another one gone, and another one gone.
But I think I'll get along fine . I think I'll be alright, for real goodbyes these aren't.
--