On 15:34 4.04.2000, Dave Sill could be heard musing >"Will Harris" <[EMAIL PROTECTED]> wrote: > >>I have embedded a Perl engine >>into qmail-smtpd which allows you to use Perl's excellent pattern matching >>system. > >Have you analyzed the impact of this on security and efficiency? E.g., >does embedding perl carry along the C runtime library, which Dan went >to great lengths to avoid? How much bigger are qmail-smtpd processes >with your patch? How much slower? > >I'm not saying the patch has no merit, I just think that you shouldn't >advertise only the benefits. > >-Dave No - I haven't done any analysis. I don't know exactly what djb-unfriendly code is included in the Perl library, but I suspect there is definitely some standard C library stuff in there. The binary is about 540k bigger on disk, and about 700k bigger in memory. I don't know how much slower it is either, but I'm not so concerned about that - it's remote users who have to use qmail-smtpd, as local users go directly to ofmipd. I'm sure there are some problems associated with embedding Perl in any program, but I kind of expect that people who can patch code, compile it, configure qmail, and write Perl regular expressions would already be aware of that. I don't care about advertising my patch - I just thought some other people might be interested in it's features as well, so I posted a message to the list saying what it does. Perl does have an excellent pattern matching system... That said, we can look at DJB's seven rules for the design and implementation of qmail, and see where my patch falls short: 1) Programs and files are not addresses. Don't treat them as addresses. - does not apply to this patch 2) Do as little as possible in setuid programs. - does not apply to this patch 3) Do as little as possible as root. - does not apply to this patch 4) Move separate functions into mutually untrusting programs. - if there's a security breach because of Perl, it still doesn't affect system security, because none of the other programs trust qmail-smtpd. 5) Don't parse. - my patch doesn't parse user input, and it doesn't provide a user interface (other than Perl regular expressions). There is no user interface exposed to anyone other than the postmaster/sysadmin. I will admit that sysadmins can easily write incorrect regular expressions (as I did earlier today) but what of it? 5) Keep it simple, stupid. - okay, it's not so simple any more. I think the extra functionality is worth it. In addition, the patch is very, very simple, and is completely disabled by commenting out one line of code if you think things are going horribly wrong. 6) Write bug-free code. - I don't know if Perl is bug free. I doubt it. My patch may not be bug free either. I have tested it quite thoroughly though. Bug reports are always welcome. So there you have it - total disclosure. In the README for my patch I say "use at your own peril", and I think that about covers it. If you don't like the idea of using someone else's code, don't use my patch. If you think it's worth it, use it. regards, Will __________________________________________________________________________ "I was going to be a Neo-Deconstructivist, but Mom wouldn't let me..." multimedia laboratorium [EMAIL PROTECTED] institut fuer informatik (pgp id) F703D035 der universitaet zuerich (office) +41 1 635 4346 winterthurerstr. 190 (fax) +41 1 635 6809 ch-8057 zuerich (mobile) +41 76 372 0913 switzerland www.ifi.unizh.ch/~harris __________________________________________________________________________
