Subject: Re: lpwrapper
To: None <>
From: gabriel rosenkoetter <>
List: tech-userlevel
Date: 03/20/2003 20:12:35
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 20, 2003 at 07:48:38PM -0500, der Mouse wrote:
> If the caller execs /usr/ucb/lpr (or whatever full path the author felt
> like using), it's broken (or nonportable or whatever your favourite
> adjective for such cases is), and this is just one of multiple reasons
> why.

Great (and I agree!), but "that's broken" doesn't change the fact
that a lot of things (ones I used today: Opera, Phoenix,,
all installed out of pkgsrc) presume you want to use /usr/bin/lpr.
Some let you configure them otherwise, but that's overhead for
every single one. And no, trusting $PATH doesn't necessarily work;
wrapper scripts for big, GUI applications periodically choose
(wrongly, but it happens) to stamp on it. Why should NetBSD shoot
its users in the foot when we've already got a great way to avoid
it in emulating mailwrapper?

I've changed my mind since earlier today; I think that it doesn't
matter if we ever want to switch lpds (and, don't kid yourself,
we're not "switching" MTAs any time soon either), it's still
reasonable to have an lpwrapper.

I couldn't agree more with Bill Studenmund and Ben Harris about
this: sendmail and lpd ARE special as far as daemons go. I think
newservers (like INN) are too, but we don't install any of those
by default.

So I would say: It's practical to wrap lpd for the same reasons
it's practical to wrap MTAs that are actively sendmail runalikes
(certainly, some aren't; qmail comes to mind). It is NOT practical
to wrap sshd, inetd, named, or any other daemons I can think of in
a quick enumeration right now. But there really is a clear criterion
for whether or not it'd be appropriate.

gabriel rosenkoetter

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.1 (NetBSD)