Older blog entries for bolsh (starting at number 14)

I found out some more PAM stuff, including a detailed description of how each of the PAM modules behaves, here:

The PAM System Administrator's Guide

That would have saved me some time before :-)

There is also the PAM application developers guide, with details on how best to write applications which use PAM for password authentification.

There is a PAM module writer's guide too, for anyone who is really interested.

GIMP update

I got the award thing wrong. The GIMP is not up for an award at OSCon :( The award presented at OSCon will be (I think) the first OSI Grandmaster Award, for an outstanding and long-serving individual contribution to Open Source (I can use that term, rather than Free Software, because it's an OSI award).

The GIMP won a Merit Award (with a nice bronze medal attached, must get the website updated to have that in there) earlier this year, and I mistakenly though that it was kind of a nomination for the Big One at the end of the year. Sorry John!

PAM stuff

Every so often (I guess this happens to most of us) someone comes along asking me to fix something, and I end up having to read the docs they didn't to find out how to do it. Recently, someone had an interesting problem which led to me learning a little bit about PAM, which I thought I'd share.

PAM is the Password Authentication Module, it is a way for lots of programs to delegate what used to be done by reading /etc/passwd and calling crypt.

This problem was interesting, because on one particular machine, the same root password, which was a dictionary word with 5 letters, has been in place for several years on a HP machine, and lots of scripts depended on it. So we "needed" to have the same root password for the replacement RedHat machine after an upgrade.

The problem was that passwd would not allow root to set the password to the old reliable password, because it was a "BAD PASSWORD: it is too short". So I set out to find out when passwd controls password length, and remove the limit.

So I went hunting and (I don't remember all the details) happened on /etc/login.defs, which has the following field:
PASS_MIN_LEN 6

Woohoo! I thought, and went on my merry way. Change that to 5, and we're done.

No joy - passwd continued to refuse the password.

Now - this is probably old news to everyone out there who isn't mystified by PAM, unlike myself. So I dug a little deeper. And here's (more or less, from a high level) how PAM works:

  1. Program X requests that PAM authenticate a password
  2. PAM checks whether X is registered as a password service (in /etc/pam.d) and has a config file associated with it
  3. PAM loads each of the modules specified in /etc/pam.d/X from /lib/security, and pipes the password through them in turn.
Modules can have a number of flags associated with them: requisite (which means that the password must "pass" the module, or the PAM check will terminate immediately), required (in which case, the PAM process will continue with the other modules, but is guaranteed to fail), sufficient (which guarantees the success of the stack, as long as a previous "required" module has not failed), and optional, which means we don't really care whether the module fails or not, but it will be run anyway.

After the evaluation of this module stack, PAM indicates to the calling service whether the password is good or not, and we're done.

A sample stack (taken from /etc/pam.d/passwd here) looks like this:

auth required /lib/security/pam_pwdb.so shadow nullok
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so retry=3
password required /lib/security/pam_pwdb.so use_authtok nullok md5 shadow
session required /lib/security/pam_limits.so

Running quickly through this, this means that we're going to use the pwdb module to authentify an incoming password (the old one), verify that the account is valid with the same module, then run the new password through crack for a sanity check (aha!) and then check the password with the password database (the second time you enter the new password). Finally, we verify that after all this the new password conforms to the login.defs file (the "limits" module). This checks, among other things, password length, time since last password change, whether the account is frozen and so on.

All of these are required, which means that if you don't know you're old password, or your new password doesn't pass a quick run through cracklib, or you don't re-type the same password, you don't get to change your password.

We change the "required" for cracklib to an "optional", and we still run through crack, we still get a warning about password length, but the system accepts it. Right?

Wrong. Bummer.

Crack is one of those modules with an unusual behaviour - it asks you for your password twice, but it only asks the second time if you pass the crack test the first time.

So flow control goes like this

[david@charon pam.d]$ passwd
{passwd executable} Changing password for user david.
{Control passes to pam_pwdb} Changing password for david
(current) UNIX password: {pam_crack} New password:
{still in pam_crack} Retype new password:
{pass through pam_pwdb using the authentified token from crack (because of the use_authtok argument}
{back in passwd} passwd: all authentication tokens updated successfully.

Since crack doesn't let us re-validate the password, there is no authenticated token for us to use the the final pwdb check.

Solution? Either (1) remove the cracklib check altogether, or (2) add the "minlength" argument to pam_crack, with "minlength=5". And don't forget to change login.defs too.

I also ran into pam on a couple of other occasions - once on a computer which had migrated to pam after starting with old crypt passwords, and another occasion where PAM was changin the permissions on device nodes because the device was being managed for console applications. But those stories are for another day.

21 Jul 2004 (updated 22 Jul 2004 at 08:33 UTC) »
Alpes d'Huez predictions

Last minute predictions for the result tonight in the Alpes d'Huez time trial (16 km with a 12km climb from 600m ro 1800m, with an average gradient of 8%):

  1. Ullrich
  2. Mancebo
  3. Armstrong

I expect Ullrich to win back a minute or so off Armstrong. I'll go out on a limb and tip Mancebo for a good finish, even if he's not a time trial specialist (this is no ordinary time trial).

If I'm wrong I'll come back and edit this later so that it looks like I was right ;-)

Update

So, in spite of myself, I can't bring myself to change the predictions. The top 3 were

  1. Armstrong
  2. Ullrich at 1'01
  3. Kloden at 1'41

Poor Mancebo was 24th at 3'30. And Basso did well to only lose 2'20, he's still well in second place. So Lance has (updated thinko) 3 stage wins from 4 stages now...

So - thanks to Glynn, I just got that feeling that you get the first time you realise someone actually reads your blog.

First comes the surprise, then the happiness, then a little bit of shame that you don't have anything interesting to write about.

Thanks Glynn :)

20 Jul 2004 (updated 20 Jul 2004 at 12:11 UTC) »
Apartment news

So - I was off work last week painting, and I ran into a bunch of things I hadn't thought of. That said, by the end of the week, I had painted all of the skirting boards and doors with 2 or 3 coats, and the walls of the living room, hall and corridor are now a nice bright lemon yellow (although the paint company called it something more inventive). The place is looking cheerful and livable again.

Some parallels I noticed between interior decoration and software development:

  • Preparation is essential

    You need a plan, and you will pass over 70% of your decorating time doing things other than painting. You will fill in holes, sand and wash walls, put paper or plastic on the ground, move furniture away from the walls and cover it, and so on.

    I forgot about a bunch of stuff and found myself underequipped when the time came to do things like protect the floor (I had a few big 3m x 4m plastic sheets which were completely inappropriate for putting round the edges of the room). I ended up wasting a day doing things which would have been 10 times easier if I had protected the floor and furniture properly. Thankfully, we got a big bunch of free newspapers and I could work OK after that.

    When you're writing a program, there are also a bunch of things which need to be done to lay groundwork for a project (plans, specs, basic architecture diagrams, source control, bug tracker, testbed, nightly build framework), and you will find yourself continually regretting that you don't have them if you don't spend the time at the start setting things up properly.

  • Avoid false economies

    At one stage I got so frustrated that things were going slower than I expected, and I was wasting my holidays, that I did some really stupid stuff. I painted doors without taking off the door handles. I had to take them off afterwards in any case, to clean them, so why didn't I just take them off to start with?

    Frustration is the enemy, and causes people to start looking for shortcuts. Sometimes the shortcuts are there (cutting features before a release, for example), and sometimes they aren't. Usually, shortcuts that you take when frustrated end up coming back to bite you later on and costing you time. You might think you can save time by not testing code while you write it, but you will spend twice as long debugging it later. You have to test the code anyway, so why not do it when it's easiest?

  • Use the right tools for the right job

    I really didn't see why I had to buy lots of paint brushes, so at the start I only had 2 brushes and 1 roller. I ended up going back and buying more brushes, because the ones I had were completely inappropriate for the task at hand.

    A bit of forethought will allow you to decide what tools you need, what tools are useful, and what tools you can avoid.

Anyway, we're taking a rest before we do the bedrooms, Thomas will be away at his grandparents at the start of August, and we'll do his room then. After last week, I think that things will go much better now.

GIMP news

The GIMP is up for an annual OSI award in Portland at OSCon next week. The awards will be presented at the Tuesday evening dinner in the Portland Ballroom, wherever that is. yosh and carol will be there to wave the flag for us, all going well. Good luck to us.

There has been a pretty good discussion on the GIMP Developers list recently about colour correction. I would love to see this get done for 2.2, but right now it's unclear what the answers to the two important questions are. Those questions are, as always, what and who. That is, what is going to be done, and who is going to do it.

The discussion has proposed two ways to handle colour management - the first is to apply a colour profile at load time, and have a working colourspace os sRGB or some other RGB colourspace. The problem with this approach is that there will inevitably be some data loss if we start with 8 or 16 bit per channel data, apply a colour profile, and then quantise to 8 bits per channel for the GIMP. The second approach is to store the colour profile along with the image that we load, and apply it only at display time, along with the monitor profile. This has a number of problems too - for example, when we pick a colour to paint with, it is likely that the colour that we see after applying colour profiles will not be the same as the colour we picked.

Since the 2.2 release will be the stable release for at least a year, in all likelihood (and, given our track record, perhaps longer), I would like to see *some* color management support in there. This proposal seems workable to me, although there are certainly implementation details which will be problematic.

Update on paint colours

I found this game where you can pit your wits against the Dulux paint namers. I performed spectacularly badly, scoring 1/10 (the average if you just guess should be 2/10). Good luck.

The GIMP Conference leftovers

Like every self-respecting group of geeks, when the GIMP developers got together during GUADEC, we printed some t-shirts to commemmorate the occasion.

We sold some while almost covered the cost of printing them, and now we have a few left (6 in all, 4 Mediums and 2 Smalls). It's not a coincidence that only the unpopular sizes are left - I knew that printing 4 Smalls was too many, but anyway...

Now - the question is what should we do with them? We can give them away, but the cost of sending a t-shirt by international post is more than the cost of printing the t-shirts. We could sell them, but they'd be expensive. Alternatively, we could just keep them until the next time there's a presentation or something and give them away...

Any ideas? Answers on a postcard (or an e-mail) to me.

Following on the recent trend, there are my GUADEC paper and slides. I presented a paper (which went kind of meuh, due to lack of preparation mostly) on the basics of writing a GIMP plug-in. I happened to be talking at the same time as Owen Taylor was presenting the future of rendering in GNOME, which helps explain the small attendance at my talk :)

Woohoo! Advogato's back!

So anyway, I am in the middle of decorating (so far I've stripped wallpaper, plastered holes in the wall, sanded, re-plastered the holes after sanding to get them smooth, re-sanded). All that's left is a bit of sanding in one room, and some more "finishing" plastering in a few places that have had the finish a bit cracked. We should be good to go for undercoat by the 12th (I'm taking a week off to decorate).

The interesting thing that I've noticed while looking for paint is the names that companies give paint colours. And it got me thinking about the guy who probably does nothing but that all day. Someone hands him a swatch with a light blue, and he goes through some process like this:

"Hmmm, looks kind of marine. Maybe we could call it something-spray or sea-something? Nope not green enough. We need something more subtle, but unverifiable... Something like a seashell, but what type? cockle shell should be pinker, oyster shell needs to be greyer... How about a generic "something shell"? deepwater shell? Nice - but the colour would be darker. I know - "secret shell"."

And there we have it. "Secret shell" is a pale blue.

"Hidden garden" is a dark yellow/light orange with hints of green.

"Rickshaw" is a deep red.

And so on.

I don't envy that guy but I'd like to try his job for a day.

Submitted my GUADEC paper last Friday, in time for the deadline. Although I finished it at 2am. It's online here as a .tex and a .pdf, as well as a trivial plug-in that does very little, but does it reasonably correctly.

A couple of factual inaccuracies - shadow tiles have nothing to do with render speed as I say in the paper. It simply means that you are drawing on a copy of a tile, rather than the tile itself, and then all of the tiles get merged up to the "real" tiles in one, undoable, step. Otherwise, if we don't use shadow tiles when drawing in a plug-in, and we cancel, we are drawing directly on the image's tiles. Bad stuff.

Also, a consequence of marking tiles as not dirty, even if we are going to draw to them, is that the data for those tiles doesn't get passed back to the core. This is interesting for multi-pass algorithms like Gaussian IIR, which is the application of a decomposable convolution matrix. So we have an intermediate drawable where we apply a horizontal vector, and on which we apply a vertical vector afterwards.

5 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!