Date: Mon, 11 Oct 1999 23:42:06 -0400 From: Brian Reichert <reichert@numachi.com> To: "Ryan Thompson [FreeBSD]" <freebsd@sasknow.com> Cc: James Wyatt <jwyatt@rwsystems.net>, freebsd-isp@FreeBSD.ORG Subject: Re: Chroot and ~/bin, ~/etc. Better way? Message-ID: <19991011234206.A24645@numachi.com> In-Reply-To: <38029482.9077F9E9@sasknow.com>; from Ryan Thompson [FreeBSD] on Mon, Oct 11, 1999 at 07:53:06PM -0600 References: <Pine.BSF.4.10.9910111606070.30594-100000@bsdie.rwsystems.net> <38029482.9077F9E9@sasknow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 11, 1999 at 07:53:06PM -0600, Ryan Thompson [FreeBSD] wrote:
> I consired hard links, as well (and, after reading the other messages in
> this thread, it appears others have, too :-) The problem, though, still
> remains that you can't hard link a directory (users' etc directories on
> my system contain about a dozen files). That makes for a lot of work
> when adding users or updating files. (even for a script! :-)
How so? You could easily cram in all sorts of weird stuff into,
say, /home/skel, and a script as simple as:
# cd /home/skel ; find -d . -print | \
cpio -p --make-directories --link --quiet ~/new_user
would seem to handle the creation of a directory full of hard links.
Use a private pw.conf(5) to cause create of local copies of file
you want them to be able to touch, and away you go...
> And,
> maintenance is still messy.
Maintenance of what? Certainly, if you change /home/skel after
you created ~/new_user, you'd have to re-sync, but so what? Re-run
the cpio thang...
> AND, ln won't create hard links across file systems... LET ALONE NETWORK
> CONNECTIONS :-) So, that pretty much cinches it for me, as home
> directories can exist on multiple systems, here.
Hence, my original condition that said skel tree be placed on the
same drive at the home directories.
Consider the magic of rdist, etc. You have no idea how much
diskspace/ bandwidth you'd save by have a local tree per disk hosting
ftpgroup users...
If you are working in a distributed environment, and you are not
making use distributed syncronization tools, you will invent a
maintenance nightmare for yourself in the long run...
> And, as James (below) has mentioned... There is still the security
> issue. And, in a few specialized cases on my system, I have special
> requirements for the /etc and /bin directories, and, with hard links,
> maintenance becomes very bothersome.
See below.
> > We considered having all the ftpgroup users share ~/bin and ~/etc dirs
> > with linked copys of the files, but figured that if anyone of them could
> > somehow find a way to update their /bin/ls or something, they could trojan
> > it for the others. They could also try cracking the other accounts if they
> > knew of them in the shared password file - though they wouldn't have the
> > crypted passwords. Obviously symlinks wouldn't work in a chroot()ed env.
If you've properly created the chroot'ed account as per suggestions
in ftpd(8), then you will be probably as safe as you can get. If
someone can write to a root-owned file (irrepsective of a chroot'ed
environment), then they can trojan whatever they want, anyway.
> > We also couldn't think of anything better to support users changing their
> > own passwords than having /bin/passwd as their shell. EDI users usually
> > don't change their passwords often anyway...
I would have thought that if you are chroot'ed, then you simply
could not affect your system-wide password. Am I missing something
here? I've worked in environments where we put together a secure
(as in 'https') web server/CGI solution for people to 'log in', as
to affect some (but not all!) fields of their password entry.
--
Brian 'you Bastard' Reichert reichert@numachi.com
37 Crystal Ave. #303 Daytime number: (781) 899-7484 x704
Derry NH 03038-1713 USA Intel architecture: the left-hand path
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991011234206.A24645>