Subject: Re: UUCP removal from OpenBSD
To: Feico Dillema <>
From: Greg A. Woods <>
List: current-users
Date: 09/30/2001 14:20:20
[ On Sunday, September 30, 2001 at 15:43:11 (+0200), Feico Dillema wrote: ]
> Subject: Re: UUCP removal from OpenBSD
> Whether it is obsolete or not, is not the question here. Fetchmail is
> not obsolete either, nor is gnome or whatever. However, that's no
> reason to have those in the NetBSD base system. Question is whether a
> large enough fraction of newly installed NetBSD systems actually
> have any use for it ever, and how high the price of its absence
> is for those that do need it, to warrant its appearance on
> *all* installed systems.

UUCP has come as a "base" part of most every Unix since V7.

Fetchmail has not come as a base part of any Unix so far as I know.

UUCP is (still) the de facto standard way for any Unix to transmit files
and do remote execution.  It works over almost any kind of data
transport imaginable.  It works well over unreliable data comms.  It is
reliable and reasonably robust in the face of system crashes too, and
has reasonable data integrity and good logging.  It only lacks modern
authentication mechanisms (and instead more or less still assumes the
data transport layer it uses is secure from sniffing and
man-in-the-middle attacks just as most dial-up effectively is), though
in many ways the relatively low privilege it is given by default
mitigates the need for very strong authentication.

> On a related note, would it be `A Good Thing' to have certain binaries
> that need setuid, have their setuid bit stripped by default, and then
> set it only after configuration (like UUCP=YES in /etc/rc.conf etc)?

No, that would be a bad idea.

As much as I dislike having too many set-ID binaries, and as much as I'm
afraid there are major flaws in the use of set-ID in Taylor UUCP, it
would in general be a very bad idea to turn on set-ID bits just because
someone enables something in /etc/rc.conf.

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>     <>
Planix, Inc. <>;   Secrets of the Weird <>