Xref: utzoo comp.unix.xenix:10190 comp.unix.i386:3053
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcdchg!chinet!randy
From: randy@chinet.chi.il.us (Randy Suess)
Newsgroups: comp.unix.xenix,comp.unix.i386
Subject: Re: Using UUCP under a BBS system???
Message-ID: <1990Feb19.135042.3950@chinet.chi.il.us>
Date: 19 Feb 90 13:50:42 GMT
References: <1990Feb18.212134.15800@ddsw1.MCS.COM>
Reply-To: randy@chinet.chi.il.us (Randy Suess)
Organization: Chinet - Chicago Public Access UNIX
Lines: 62

In article <1990Feb18.212134.15800@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:
]>]
]>	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)
]
	Picospan has hard coded path names in it, so I had to have
	two versions, one in the chroot partition pointing to
	the normal conference tree, /usr/bbs and the modified pico 
	pointing to the chrooted partition, /usr/guest/usr/bbs, 
	usr/guest being the chroot partition.

]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.
]
	Picospan was designed back when UNIX ran on tube based computers.

]>       Email was strictly within the chrooted area.
]
]Which is a problem if you want people to be able to get/send offsite mail :-)
]
	Which was the primary reason for running the chroot stuff.  
	Temporary guests can't email AT&T source code to themselves.
	This is what started the whole security paranoia thing.
	Seems chinet is used alot by local Bell Lab's people.
	I have more fake logins belonging to AT&T Security people
	than regular users!

]>	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.
]
	I decided that I am running an public access UNIX system, and
	if guests cannot access all that UNIX can give them, I might
	as well shut it all down.  Paranoia was no fun.

]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.....
]
	It is interesting that I havn't seen anything on the net
	about the above.  A local UNIX bbs was shutdown/confiscated
	by a 3 letter agency because of having the unfortunate
	distinction of being home to the 911 crackers a few weeks
	back.
]Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)

-- 
Randy Suess
randy@chinet.chi.il.us