[maceye]

Is there any way that I can create an ftp login/password that has access to only one directory? I am running OS X 10.2.4, and I can;t figure out how to do this. I tried assigning my ftp login its own group (I created my own), but this didn't help. I can still browse large portions of my hdd.

[RavenEA]

It's not exaclty what you want, but sharepoints is a fantastic sharing app that lets you dictate points to share with samba and afp.

[Arkham_c]

Originally posted by maceye:
Is there any way that I can create an ftp login/password that has access to only one directory? I am running OS X 10.2.4, and I can;t figure out how to do this. I tried assigning my ftp login its own group (I created my own), but this didn't help. I can still browse large portions of my hdd.

It's supposed to be easy. However, there's a bug in the ftpd daemon that comes with OSX. Luckily, you can download the source from the Darwin archive, patch, and recompile.

If that sounds like too much work, you can download it precompiled from me here:

http://onyx.theresistance.net/files/ftpd_fixed.tgz

Once you have it, move the one in /usr/libexec aside and put it in its place.

Then, create a file called /etc/ftpd.conf. In that file, do something like this:

Code:
chroot REAL /usr/local/ftp_dirs/%u
homedir REAL .

That will make users ftp root be /usr/local/ftp_dirs/username where username is the users' login. Change the directory in the example to the one you want to use (make sure it exists).

[gatorparrots]

It might seem extreme, but rather than fixing the broken ftp daemon, I suggest replacing it altogether:

Apple's decision to switch ftp daemons from ftpd in 10.1 to lukemftpd in 10.2 is of questionable merit. The lack of updated documentation to reflect that decision is truly lamentable. Most users upgrading from 10.1.x are left hobbled or with malfunctioning ftp servers (especially in regards to chroot functionality), with no changes in the man pages to help them configure their new ftp daemon.

Rather than remaining in that state, I elected to replace the built-in ftp server with pure-ftpd, a fast, robust, and feature-rich ftp server that also boasts no root exploits.

The first step is to download and unpack the source. First, change directories to wherever you keep you downloads or source code:
cd /downloads
curl -O ftp://ftp.pureftpd.org/pub/pure-ftpd/rele...d-1.0.14.tar.gz
tar xzf pure-ftpd-1.0.14.tar.gz
cd pure-ftpd-1.0.14/
./configure --with-everything --without-banner --without-humor --with-virtualchroot
(This will configure a 'big server' with a plethora of options, including throttling, ratios, ftpwho, quotas, but will leave off the guady initial banner and the sprinkling of colorful banter in the error messages, etc.)
sudo make install-strip

At this point you will need to choose which server type you desire, as pure-ftpd can run in either standalone or xinetd mode:

Standalone Mode
You can run the server in standalone mode with this command:
sudo /usr/local/sbin/pure-ftpd &
or if you desire, use command line switches to configure the server at runtime:
sudo /usr/local/sbin/pure-ftpd -A -E -p 40000:50000 -c 5 -C 1 -I 5 -T 25 -u 1 &

The command line switches I have chosen tell the server the following:
-A chroots everyone
-E only allows authenticated users; anonymous users disallowed
-p 40000:50000 specifies the port range for passive connections
-c 5 specifies the number of clients
-C 1 specifies the number of connections per IP address
-I 5 changes the idle timeout; default 15 minutes seems excessive
-T 25 throttles the bandwidth to 25KB/sec per user
Many other switches are available. See the documentation for a complete list.

To get the standalone server to launch automagically at startup, you would have to write a Startup Item:
http://www.macfora.com/forums/showthread.p...=&threadid=6314

xinetd Mode
(As always, before editing a system level file, it is wise to create a backup first.)
cd /etc/xinetd.d/
sudo -s
cp ftp ftp.default
pico ftp

Modify the server and server_args lines as folows:

Code:
service ftp
{
        disable = no
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/local/sbin/pure-ftpd
        server_args     = -A -E -p 40000:50000 -c 5 -C 1 -I 5 -T 25 -u 1
        groups          = yes
        flags           = REUSE
}

Restart xinetd to affect the changes (if you have the existing ftp server running):
kill -1 `cat /var/run/xinetd.pid`
exit

Test to confirm that it is working:
ftp 0

If you get something like this:

Code:
[gatorparrots:] gator% ftp 0
Connected to 0.
220-FTP server ready.
220 This is a private system - No anonymous login
Name (0:gator):

Congratulations! Your new FTP server is working as advertised. To enable the chroot to a single directory, simply assign your ftp users' home directories to your ftp root directory via NetInfo (and possibly put them in a dedicated ftp user group for added flexibility). Otherwise, the individual users will be chrooted to their /Users/username home directory.

[Rainy Day]

"FTP Security" is an oxymoron. If it's security you seek, consider going with sftp instead.

[gatorparrots]

Originally posted by Rainy Day:
"FTP Security" is an oxymoron. If it's security you seek, consider going with sftp instead.

SFTP is too much in its infancy to support the better feature set of FTP. Maybe in a few years it will mature enough to be truly usable. Try FTPS or stunnel-wrapped FTP for greater security. Running on alternate ports also increases security, as does disallowing anonymous FTP access and removing shell access for FTP users.

[Rainy Day]

Running on alternate ports also increases security

This technique is not likely to increase security as a port scanner will find your alternate port. One school of thought postulates that this technique could actually draw attention to your site. In any event, unless FTP connections are restricted to secure tunnels, your account name and password are still sent as cleartext and can therefore be sniffed.

as does disallowing anonymous FTP access

Anonymous read-only FTP access, which doesn't expose account passwords, is arguably a more secure form of FTP access than writable FTP access with a password.

removing shell access for FTP users.

Definitely a good idea.