Why doesn't uucico use chroot(2)?

[Carl S. Gutekunst]

The chroot 'world' would have to be set up such that all commands exec'd under
uuxqt would run normally. This includes rmail, rnews, and (on a BSD system)
sendmail. So your chroot directory tree would need links to /usr/lib/sendmail,
/etc/passwd, and a whole buncha other files that do not normally live in the
same partition. For some files, on a BSD system you could use symbolic links;
for others, you would have no choice but to maintain multiple copies. (Making
/etc/passwd a symbolic link is OTQ, for example.) And you would now have some
of the files you wanted to protect in the chroot tree!

Getting it right -- and *keeping* it right -- would be a difficult task if not
impossible. You could have uucico to move the root back before it forks uuxqt,
but then you lose most of your security.

In addition, uucico would be totally unable to reference any user files; this
would rule out the use of the '-c' option to uucp and uux. But it appears that
is what you want.

Uucico would also have to be suid to root, but only long enough to do the
chroot(2) call.

In short, this may have merit in specific applications, but the little bit of
security gained is not worth the hassle for most environments.

<csg>