Using UUCP under a BBS system???

[Karl Denninger]

In article <1990Feb18.180120.22530 at chinet.chi.il.us> randy at chinet.chi.il.us (Randy Suess) writes:
>In article <1990Feb15.204106.8719 at ddsw1.MCS.COM> karl at mcs.MCS.COM (Karl Denninger) writes:
>]
>]We used to run with a "chroot()"ed area.  So did Chinet, if I remember
>]correctly.  Neither of us do now.  Hmmmm.... I don't know why Chinet stopped
>]doing it, but I do know that disk consumption was part of the reason we
>]quit.
>]
>	This was during the time of extreme security paranoia.  Chroot
>	(under sysVr3.1 on a 3b2) worked out quite well, including
>	a complete seperate set of /dev entries, links to most /usr stuff
>	(/bin and /etc stuff had to be duplicated).  A number of programs
>	were modified to work across the chroot partitions, including
>	the conferencing system, and the party program.  

That's interesting; I would think that if the conferencing package was
looking for a base directory (from a common reference) nothing would have to
be done other than having two "directing" files.... but then again, I know
little of the internals of Picospan (what is running over on Chinet)

In fact, AKCS was designed with just this in mind; when we were doing the
chroot thing ourselves it was during the time that AKCS was being originally
designed and that was a major part of it.

>       Email was
>	strictly within the chrooted area.

Which is a problem if you want people to be able to get/send offsite mail :-)

>	It was finally removed due to other policy decisions, not because
>	of unworkability.

Yep.  We stopped using it here partly because of problems with disk space
(we don't have unlimited room available on that machine) and partly due to
the decision which was made not to grant shell access to other than system
contributors.  It certainly did work, although we never put the time into
making email operate properly across the chroot()ed area.

The entire "security" thing may come back with a vengence. There have been a
couple of incidents lately which may end up having a large impact on the
future of "freely available" shell access..... one would hope not, but it
seems as though allowing that kind of free roaming is asking for far more
trouble than it is worth.....

--
Karl Denninger (karl at ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"