Subject: Not-so-anonymous FTP

From: Mark Spruiell <[email-masked]>
Date: Fri, 5 May 1995 16:42:02 -0700 (PDT)

We're exploring ways to deliver software via FTP.  We don't want to use
anonymous FTP because we need more control and want to track transfers
by username.  But we also don't want to create *real* accounts on our
FTP server if we don't have to.

I've hacked up an ftpd to provide a hybrid real/anonymous account.  It
uses an /etc/ftppasswd file, which looks just like an /etc/passwd
file:

  username:password:uid:gid:gecos:homedir:shell

During the login process, ftpd checks /etc/ftppasswd for the account.
If the account is found and the correct password is entered, ftpd behaves
like anonymous FTP, in that it chroots to the specified home directory.
All of the uids and gids in the /etc/ftppasswd file would be set to the
same harmless account (e.g. nobody/nogroup).

What I like about it:

  * We don't have to create real system accounts, but we still get
    transfer records by username

  * The user is operating in an isolated file-system, a la anonymous
    FTP

  * The /etc/ftppasswd file can be read-write root only, similar to a
    shadow password file

  * We have a library of routines for safely querying and modifying the
    /etc/ftppasswd file

What I don't like about it:

  * It's a hack

  * We have to prepare each account's home directory with all of the
    anonymous-FTP trappings, i.e. /dev, /bin/ls, /usr/lib, etc.

What do you all think?  Is there an easier way that I'm overlooking?

Thanks,

Mark Spruiell
[email-masked]

---

From: [email-masked] (Dave Wolfe)
Date: Sat, 6 May 1995 19:13:48 -0500 (CDT)

[ Mark Spruiell writes: ]
> I've hacked up an ftpd to provide a hybrid real/anonymous account.

Why not just set the shell on regular logons to /bin/true or some such?
(I use a little 3-line C program I call noshell that prints a message
and disconnects, which is a little more polite than just disconnecting.)
That way it's not a *real* account but it allows ftp access. If the
user's group matches a "guest" wu-ftpd account, then they're chrooted
just like anonymous ftp. No hacks, no special files, no real shell
accounts, no unrestricted access. Just be sure to add /bin/true or
/usr/local/bin/noshell to your /etc/shells file if appropriate for your
system.

-- 
 Dave Wolfe    *Not a spokesman for Motorola*  (512) 891-3246
 Motorola MMTG  6501 Wm. Cannon Dr. W. OE112  Austin  TX  78735-8598

---

From: Mark Spruiell <[email-masked]>
Date: Sun, 7 May 1995 09:04:39 -0700 (PDT)

Dave,

> /usr/local/bin/noshell to your /etc/shells file if appropriate for your

I thought about the guestgroup mechanism, but we will probably need to
have a different home directory for each user, which complicates things
quite a bit.  To do it with vanilla wu-ftpd would require a unique
group id and a corresponding guestgroup entry for each new group.  I'm
not sure which alternative is worse...

Mark

---

From: [email-masked] (Dave Wolfe)
Date: Sun, 7 May 1995 17:30:24 -0500 (CDT)

> > Why not just set the shell on regular logons to /bin/true or some
> > such? If the user's group matches a "guest" wu-ftpd account, then
> > they're chrooted just like anonymous ftp.
> 

I fail to see how setting up a home ftp directory for each guest user
complicates things more than hacking on wu-ftpd and maintaining a
separate ftppasswd file: you just specify it after a '.' node in the
passwd file, e.g. /ftp/./home/joeuser. wu chroots to /ftp and sets the
cwd of the user as /home/joeuser (relative to the chroot). Generating
unique group ids and entries in the ftpaccess file is as simple as
operating an editor, especially if you use it to write a script to add
users. That's what I did, so it takes one command with a couple of
parameters to add a user.

Let's see, which is worse: hacking on a tried and true program and
introducing who knows what kind of bugs and security holes or using a
simple existing mechanism. Hmmm... tough choice.