Home arrow Site Administration arrow Page 3 - Setting Up wuftpd for Non-Anonymous Accounts

The /etc/ftpaccess file - Administration

For some reason, it's extremely hard to find all the documentation you need to easily set up wuftpd to allow FTP to semi-secure areas of a Unix filesystem. It's relatively simple to setup anonymous FTP, where the user has little or no access. But there are many occasions where you might want to allow users to have access to, for instance, Web site directories without allowing them to get into higher levels.

  1. Setting Up wuftpd for Non-Anonymous Accounts
  2. User environment
  3. The /etc/ftpaccess file
By: Glenn Fleishman
Rating: starstarstarstarstar / 3
April 06, 1999

print this article


Setup the /etc/ftpaccess file
The ftpaccess file controls who gets into the FTP server and how. There are a couple of associated files (like ftpusers) that you can read man pages on to get more detail, but that documentation is actually quite clear, so I won't reiterate it here.

In ftpaccess, you're creating a plan for who can do what. With non-anonymous chroot access, you want to create a set of guestgroups, each of which corresponds directly to entries in the /etc/group file. You should repeat these entries in the chroot'd group file, too, with the same IDs.

Here are the lines you need to make sure are in the ftpaccess file to make this all work. Let's assume three groups: frogstar, bilbo, and foobar. I'm only including the parts that are specifically necessary to make non-anonymous access work; you can leave the rest of the model file the same, or read the man page to figure out how to further customize.

First, you set class to allow local and remote access from all addresses. You can tune this as needed, including removing anonymous remote access.

class local real,guest * class remote real,guest,anonymous *

Then you specify all of your guestgroups, one per line. The /etc/group file has entries for each of these groups, each of which has just one member: the singular form of the name. That is, the bilbos group comprises just bilbo.

guestgroup frogstars guestgroup bilbos guestgroup foobars

You probably should log all transfers for security purposes.

log commands real,anonymous,guest log transfers guest,anonymous,real inbound,outbound

If you don't specify the following directives, they default to yes for everybody. What you're doing here is giving permission for these guestgroups to delete, overwrite, and rename files, and you're allowing everybody but anonymous to chmod or use umask.

delete yes frogstars,bilbos,foobars overwrite yes frogstars,bilbos,foobars rename yes frogstars,bilbos,foobars chmod no anonymous umask no anonymous

You also have to explicitly allow upload permission by group and directory. This is a further security protection, so that even if your users can view the contents of other directories, they can't upload into them even if they have write permission. (Study the man page for all the options on this line.)

upload /usr/www /frogstar yes root frogstars 0664 dirs upload /usr/www /bilbo yes root bilbos 0664 dirs upload /usr/www /foobar yes root foobars 0664 dirs

That's it! Enjoy! Write me with comments or improvements.

>>> More Site Administration Articles          >>> More By Glenn Fleishman

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: