From owner-freebsd-questions Wed Jun 28 10:44:55 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA15111 for questions-outgoing; Wed, 28 Jun 1995 10:44:55 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA15103 for ; Wed, 28 Jun 1995 10:44:52 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA16086; Wed, 28 Jun 95 11:37:37 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506281737.AA16086@cs.weber.edu> Subject: Re: Any way to get hard links to directories? To: gurney_j@efn.org (John-Mark Gurney) Date: Wed, 28 Jun 95 11:37:36 MDT Cc: wsantee@wsantee.oz.net, freebsd-questions@FreeBSD.org In-Reply-To: from "John-Mark Gurney" at Jun 27, 95 10:49:16 pm X-Mailer: ELM [version 2.4dev PL52] Sender: questions-owner@FreeBSD.org Precedence: bulk > > On Tue, 27 Jun 1995, Wes Santee wrote: > > > That said, anybody have any ideas on how to have the ftp daemon allow > > users who are logged in to see only their home (and below) directories > > without the ftp daemon losing access to the files it needs to operate? > > why don't you make a bin dir for every one... put hard links of ls... and > then if I remeber right... you can have wuftpd chroot to the users home > dir... just a though... TTYL... Make sure the things aren't linked shared, or they won't run. After that, modify the ftpd to open the directory containing the binaries you want them to be able to run (ls, etc.). Then chroot. When you want to run a binary, you: 1) open the current directory 2) fchdir to the binary directory 3) run the binary (ls/tar/etc) with explicit paths as arguments 4) fchdir back to the current directory 5) close the current directory Does the BSD fchdir operate like it's supposed to in this regard? I don't know. An alternative that wouldn't have the same side-effect of embedding full paths would be: 1) open / 2) then chroot ... 3) open the current directory 4) fchdir to / 5) use POSIX saved id's to become root again 6) chroot . (is fchroot supported? Don't know...) 7) go back to being the user 8) fchdir back to current current 9) run the binary 10) use POSIX saved id's to become root again 11) chroot back to the user's home 12) go back to being the user This has the (potential) disadvantage of following symlinks that the user has set up in advance out of their own area. On the other hand, why do all this? The user can still telnet in and cp the data into his area, then ftp it. Or ftp from the machine out (access limited by ftp -- normal programmatic access -- rather than by ftpd chroot restrictions. A better mechanism would be one group per user, with the user allowed to add/subtract people from his group. An alternative to this would be locking down users home directories. When they log in as themselves, they have access to their own stuff bit not to others (same for standard telnet into a shell: no access except to world readable/executable directories (with the possibility of using exclusion groups) and/or groups to which the user is a member, also with readable/executable restrictions. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.