Permissions whee!

As in any good mystery, the question is who done it? MacNN reports a flaw in Tiger, Leopard in which an authenticated copy operation gives the destination files (the copies) the ownership of the logged-in user, not of the name they used to authenticate. The question is, which user did the copy?

Let's say there's a system with Alice Administrator and Richard Regular-User. Richard downloads a new application from the intarwebs, and wants to put it in /Applications (though why? Why can't he just put it in ~/Applications like a good little user? Never mind). The thing is, he doesn't have the right to do that. Finder presents him with an authentication dialogue, and no matter how many times he enters his username and password correctly, he can't acquire that right. However, he sees Alice walking past in the corridor and asks her to enter her admin credentials. For whatever reason, she agrees - now Alice has authenticated and Alice has acquired the right to copy the files. So even though Richard requested the copy, it was actually Alice who performed it. Therefore Alice created the files at the destination, so they should be owned by Alice.

The only thing which muddies the waters (and leads to the conflict of convenience vs. security which is described in that article) is that in many, or indeed most, cases on OS X where this will arise, Alice and Richard are actually the same person - Sammy the Single (Security-conscious, hence separating their use of the system into regular and admin accounts) User. It's a convenience that as Richard wanted the files copied, Richard now owns the copy - but this defeats the point of Richard existing, which is that Sammy doesn't want to be able to change /Applications without being warned.

Interestingly the same question doesn't get asked of the sudo command - it's clear that if I type sudo ditto Foobar.app /Applications/Foobar.app it's the super-user who does the work.

Side-by-side

A frequently-heard rider on the statement that Mac OS X "is more secure than Windows" is that fewer people are prodding its weak spots, because it has fewer users. Well, Windows Vista has a market share comparative to Mac OS X (all versions), and this report describes the security statistics as being somewhat comparable, too. So there we go.

How to solve every problem in Cocoa

Yes, really, every problem. Don't think of Cocoa as "simple things simple, complex things possible" (actually, was it Cocoapenextstepsody or Perl who started with that tagline? Or someone else? I digress) but "simple things simple, complex things simple but you're looking at it wrong". With Objective-C 2.0 (particularly properties), Core Data, Cocoa Bindings and Cocoa Scripting, almost every "it doesn't work" moment comes down to getting something wrong with KVC or with KVO - either observing the wrong key, or typoing a method name such that you aren't KVC-compliant for a key you need to be, getting validation wrong or unexpectedly going down the -setNilValueForKey: path. So do yourself a favour:

#define GLInstanceMethodEntryLog(format, ...) NSLog(@"-[%@(%p) %@] entry: %@", NSStringFromClass([self class]), self, NSStringFromSelector(_cmd), [NSString stringWithFormat: format, ##__VA_ARGS__])

Now because all of the retain count bugs disappeared when you turned the garbage collector on, the remaining issues are with that bit of code the PHBs are paying for ;-)

Project: Autonomous Revolutionary Goldfish

I was going to write, am still going to write, about how silly project names get bandied about in the software industry. But in researching this post (sorry blogosphere, I've let you down) I found that the Software-generated Gannt chart was patented by Fujitsu in the US in 1998, which to me just explains everything that is wrong with the way the US patent system is applied to software. For reference, Microsoft Project was written in 1987 (although is not strictly prior art for the patent. Project does everything in its power to prevent the user from creating a Gannt chart, in my experience).

Anyway, why is it that people care more about the fact that they're going to be using Leopard, Longhorn, Cairo, Barcelona or Niagara than about what any one of those is? As discussed in [1], naming software projects (though really I'm talking about projects in the general sense of collections of tasks in order to complete a particular goal) in the same way you might name your pet leads to an unhealthy psychological attachment to the project, causing it to develop its own (perceived) personality and vitality which can cause the project to continue long after it ought to have been killed. For every Cheetah, there's a Star Trek that didn't quite make it. And why should open source projects like Firefox or Ubuntu GNU/Linux need "code names" if their innards are supposed to be on public display?

I've decided that I know best, of course. My opinion is that, despite what people may say about project names being convenient shorthand to assist discussion, naming your project in an obtuse way splits us into the two groups which humanity adores: those of us who know, and those of you who don't. The circumstance I use to justify this is simple: if project names are mnemonics, why aren't the projects named in a mnemonic fashion? In what way does Rhapsody describe "port of OPENSTEP/Mach to PowerPC with the Platinum look and feel"? Such cultish behaviour of course leads directly to the point made in the citation; because we don't want to be the people in the know of something not worth knowing, we tend to keep our dubiously-named workflow in existence for far longer than could be dispassionately justified.

Of course, if I told you the name of the project I'm working on, you wouldn't have any idea what I'm working on ;-).

[1]Pulling the Plug: Software Project Management and the Problem of Project Escalation, Mark Keil. MIS Quarterly, Vol. 19, No. 4 (Dec., 1995), pp. 421-447