Date: Tue, 28 Nov 2000 05:40:07 -0500 From: Gregory A Lundberg <email@example.com> Subject: Guest HOWTO Koos -- for the FAQ. Everyone else -- consider this a basis for a new Guest HOWTO ... it does not completely replace the current one (since I don't go into system- specific information), but it does give the basics. > My ftpaccess file does not seem to be used. or > I have upgraded my ftpd to the latest version of wuftpd but I still cannot > seem to get a user to chroot to its own directory. plus > How do I avoid having to copy the "glue" needed to get ls (as well as > compress, tar, gzip, etc.) working? or > Do I really need to copy bin/ls into every user's home directory? plus > The user is chroot'd but the initial directory is incorrect. or > How can I change the user's initial directory for FTP without changing it > for shell access? plus > How do I keep users from being able to cd out of their home directories? or > How do I keep users from being able to see and/or access each other's > files and directories? First off, almost everything you will want to do requires that you're actually using the ftpaccess file. - Make sure you have the -a option on the command line. The most common reason for failure to chroot when upgrading from VERY old versions is this option is missing. Be sure to check the -a option is not being 'eaten' by mistake. I suggest using "-a -a". If this solves the problem change it to "ftpd -a". Be sure to tell inetd to reload its configuration each time you make a change (typically by using "killall -HUP inetd"). - If the above does not solve the problem, ensure you are editing the correct ftpaccess file. The easiest way to do this is to insert a greeting clause at the top of the ftpaccess file. Before doing so, connect to the daemon using telnet or a command-line FTP client. Notice the initial greeting message. The default greeting contains the version and compile date of the daemon. Take a moment and check; make sure the version and compile date/time indicate you are running the version of the daemon you THINK you should be. By adding 'greeting brief' to the ftpaccess file, the version and date information should no longer appear. (Changing to 'greeting terse' should remove the host name as well.) If this indicates you are not editing the correct file, you can locate the actual file name. Usually, simply running the ckconfig utility (compiled when you built the daemon) will tell you the file name. Sometimes, however, this command is not installed or is outdated. You can get the information directly from the daemon using the strings command. First, locate the actual daemon executable file. I'll use /usr/sbin/wu-ftpd in this example but check your /etc/inetd.conf for the actual file name: $ strings /usr/sbin/wu-ftpd | grep '/ftpaccess' | head -n 1 /etc/ftpaccess Repeat the first set of tests using this file name. If the output does not make sense, remove the "| head -n 1" and read through the entire list; the file name will be there. (If it's not, recompile and re-install the daemon after beating up the person who hand-hacked the source to yours and obtaining a fresh copy of the source kit.) - If you're using "guestgroup" and the old "/./ hack", you need to be sure the user is explicitly listed as a member of one of the guest groups in your master group file. For example (if I used the "/./ hack"), to make myself a guest, I could say: guestgroup lundberg Some older versions of the daemon, however, would not detect that the user was a member of this group by the master password file entry. Instead, the user had to be explicitly listed. So, if I used this feature, to make myself a guest, my master group file (/etc/group) entry for this group would need to read: lundberg::101:lundberg - The "/./ hack" is no longer required to chroot guest users. In fact, I suggest not using it since the "/./ hack" can cause some problems for certain shell uses. (Plus it involves a by-hand edit of your master password file, which is almost always a bad idea.) Instead, I suggest using the new guest-root clause. This clause works buy USER NAME or ID NUMBER. When guest-root is present and matches for a user, two things happen: the master password file is no longer consulted to determine where to chroot to for matching users, the master password file no longer determines the user's "home" (for both initial directory or ~ notation). Instead, the guest-root determines the chroot directory, and the chroot- local password file determines the user's "home". On my servers, all users chroot to a common point. I do this so I do not need to copy the "glue" into every user's home directory. My users all go into a directory (actually, a file system) named /home/users so I use the following clause: guest-root /home/users Notice I do not specify any user name or ID number. This causes the guest-root to be the default; it applies unless there is a specific clause matching the user. By using guest-root, I override any "/./ hacks" which might already exist in my master password file. By using a common point for all users, I only need a single copy of the various bits and pieces needed for ls to work. In my example, I only need the following directories and files: d--x--x--x /home/users/etc -r--r--r-- /home/users/etc/.notar -r--r--r-- /home/users/etc/passwd -r--r--r-- /home/users/etc/group d--x--x--x /home/users/bin -r--r--r-- /home/users/bin/.notar ---x--x--x /home/users/bin/ls d--x--x--x /home/users/dev -r--r--r-- /home/users/dev/.notar crw-rw-rw- /home/users/dev/null Plus any other files or directories needed to make bin/ls work as well as the tar, compress or gzip programs (and their glue) if I want to use ftpconversions. (Note to Redhat Linux users: you get all the necessary glue by installing the anonftp RPM into the chroot area.) Guest-root only applies to guests. I recommend making EVERYONE a guest. I do that by using the new "guestuser" clause with a wildcard: guestuser * On versions through 2.6.1, due to an oversight on my part some time ago, you will also need to add the following: realuser ftp Otherwise anonymous users will become guests as well (which is bad). This anachronism is corrected in versions after 2.6.1 (which, as I write this, has yet to be released). - If, at this point, your user is not chroot'd you are not running the most-recent version of WU-FTPD. Obtain the source kit for the current version, recompile and repeat the above steps. When using the "guest-root" clause, the user's initial directory (and "home" for ~ notation) is taken from the chroot-local password file. It becomes CRITICAL that this file be "locally correct." By that, I mean that the home directory entries in the chroot-local password file be correct when viewed from INSIDE the chroot. (In fact, it has always been important that the local password file be locally correct, but this distinction becomes critical when using guest-root.) Using my account as an example, my master password file entry looks something like: lundberg:*:101:101:Gregory A Lundberg:/home/users/lundberg:/bin/sh Remember, I use guest-root to chroot all users to /home/users. So my chroot-local password file is /home/users/etc/passwd. The "locally correct" entry for me in this file reads: lundberg::101:101::/lundberg: Notice, for security, to avoid leaking any information I don't absolutely need to, I've also removed all unnecessary information. Many of my customers use FTP to manage their web sites. For them, I'd rather their FTP client see their web directory as "home". But I need to leave their system home unchanged (so Apache can find their site properly). On many systems, web pages are stored in ~/public-html. To modify my account to my FTP starts in my web pages rather than my "home", I simply change the chroot-local password entry to read: lundberg::101:101::/lundberg/public-html: At this point, my users are chroot'd and starting in the proper directories. But they are all chroot'd to a common point. I don't want my customers to be able to view each other's files (or even be able to use FTP to determine who my other customers are). For this, I use the restricted-uid clause. I restrict everyone (including myself) to their "home". Remember, the guest-root clause changes the determination of "home". By adding the following clause, my users are no longer able to access files outside their "home" (even via a symbolic link): restricted-uid * Note this applies to real users as well. Think of restricted-uid as a "soft" chroot. The effect is (or, at least, should be) the same as a chroot, but without the problems incumbent with having actually done a chroot (by that, I mean, mainly, having to copy the "glue" around so ls works). A few words of warning: although restricted-uid works to give an effect much the same as a chroot, I VERY STRONGLY discourage it's use in place of making users guests. While it appears to work properly, I never trust any single feature to provide the level of security I want. So I make my users guests AND restrict them to their homes. This way, if a user should find a way to work past the restricted-uid feature to access files outside its home, access is still limited to the chroot area. Now, having done all this, go read the Upload Configuration HOWTO.
Last updated: Wed, 16 May 2001 09:58:47 -0400