jms1 at jms1
May 9, 2008, 10:19 PM
Post #3 of 3
(156 views)
Permalink
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2008-05-08, at 1733, Hugo Monteiro wrote:
>
> From the documentation i've seen, the representation of the data
> isn't more than a record like "+keylen,datalen:key->value", where
> there's the possibility of the same key to point to different
> values. So i started testing with a self made cdb file like the
> described above and the code behaved properly. Hurray!
note that the "+keylen,datalen:" and "->" portions are added by
cdbdump to make the output more easily processed by humans. the same
tags are read by cdbmake when building a cdb file.
for a line which looks like this:
+13,34:jms1[at]jms1.net->$1$xxxxxxxx$xxxxxxxxxxxxxxxxxxxxxx
the key is actually the 13 bytes "jms1[at]jms1.net", and the value is
actually the 34 bytes beginning with "$1$". by explicitly specifying
the lengths ahead of time, it becomes possible for both keys and data
to include any bytes, including newlines and nulls.
> Then i tried with an aliases.cdb file and a cdb file generated with
> qmail-newu and i didn't get anything. Taking a closer look to the
> dumps of those cdbs, i saw that the data was represented differently
> from the cdb i made, and even from each other.
the qmail-newu program reads users/assign and writes users/cdb. i'm
not sure where "aliases.cdb" comes into play, unless this is a
mangling of the filename.
the actual formats of the keys and data within users/cdb are changed
somewhat from how they appear in users/assign; this is done to allow
qmail-lspawn to more easily work with the data.
the keys are stored as "!" followed by the "local" part (the virtual
userid), possibly followed by a "wildcard" character. the list of
wildcard characters is also found in the cdb file, as the value
assigned to the key which is the empty string (i.e. the line starting
with "+0," in the output of "cdbdump".)
the data are stored pretty much as-is from the users/assign file,
although the ":" field separators are stored as null bytes (hex 00) so
that when they're read into memory, each string will be self-
terminating (in C, a null byte marks the end of a string.)
> aliases.cdb keeps data in the format "+keylen,datalen::key[at]->&data",
> where the ":" and "@" are part of the key, and the "&" part of the
> data.
i'm not sure where this file comes from (unless you're using that add-
on program which lets you use a sendmail-style "aliases" file instead
of maintaining .qmail-* files in /var/qmail/alias... is that it?) so i
don't know how those are built, stored, or used.
> then, cdb generated with qmail-newu has the format "+keylen,datalen:!
> key->data", where the "!" is part of the key.
the "!" will always be there in the key. qmail-newu adds it, and qmail-
lspawn searches for it.
> Of course i could write code to handle those "artifacts", but i'm
> not confortable doing so without understanding them. I'd like to
> know if there is any reason for them, what that reason is and if in
> terms of recipient checking/lookup it would be a bad thing if the
> code would just circumvent them. I would like to know also if there
> are more "artifacts" that i should be aware of.
the best documentation is qmail-newu.c and qmail-lspawn.c in the qmail
source code- that's what i just read in order to figure out the
explanation above.
as for why they're there... djb's documentation is a bit sparse. i
would imagine he had good reasons at the time- if you want to email
and ask him, and he actually answers you, let us know. the point is
that they ARE there.
as for there being any more "artifacts", as you call them... examine
the source code for the programs which read and write the cdb files
you're interested in.
- --------------------------------------------------------
| John M. Simpson -- KG4ZOW -- Programmer At Large |
| http://www.jms1.net/ <jms1[at]jms1.net> |
- --------------------------------------------------------
| Hope for America -- http://www.ronpaul2008.com/ |
- --------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkglMGIACgkQEB9RczMG/PuJgACgjwFThF2QW6yGuRb5dH1o1pDo
HE4AnAqJM7Riz+EuvzRrbNFPj46HFkiX
=v21a
-----END PGP SIGNATURE-----
|
