Subject: [638] Closed user group

From: Lim Gek Meng <[email-masked]>
Date: Sun, 06 Nov 1994 21:58:41 +0800 (SST)

Hi all,

I am very new to this and would like some assistance in configuration of 
the ftpd.

I would like to set up a closed user group for ftp such that people in 
this group can upload and download files. I believe this is done using 
the configuration file ftpaccess, however, I have no idea what should be 
done.

Is there any paper or documentation available on wu-ftpd?

Appreciate any help .

regards.

**************************************************************************
*  LIM GEK MENG       *	"Whatever you do will be insignificant,		 * 
*  SingNet            *	but it is very important that you do it."	 *	
*  SINGAPORE TELECOMS *	--Mahatma Gandhi				 *
**************************************************************************

---

From: Morgan Davis <[email-masked]>
Date: Sun, 06 Nov 1994 22:34:47 -0800 (PST)

CTSNET has recently installed WU-ftpd 2.4 and we had expected to see
an anomaly from the previous 2.1 version go away with the new release.
The problem was that it took a very long time to get into the server
after connecting -- like 30+ seconds.  The new version didn't appear
to fix this, so we began to look into the source for the trouble.

Turns out that due to having 200+ 'upload' lines in our ftpaccess file
for users who have their own private, protected 'incoming'
directories, the server, upon starting a new session, has to scan the
password file TWICE (containing thousands of lines on our host) to
resolve the user and group ID numbers.

We calculated that for the worst-case scenario on our server, nearly
one million /etc/passwd entries had to be processed (with close to 500
open and close calls to /etc/passwd) just to begin a *single* ftp
session.

I'd like to offer and suggest the following modification for inclusion
in future releases.  Basically, instead of hundreds of lines like the
following in ftpaccess:

upload /usr/spool/ftp /pub/USER/incoming   yes  USER     GROUP  0600 dirs

...our simple modification provides for the following single entry:

upload /usr/spool/ftp /pub/*/incoming      yes  *        *      0600 dirs

The /pub/*/incoming dirglob matches the users' incoming directories.
The * for USER and/or GROUP specifications causes uploads to be
stamped with the user and/or group of the directory itself.

Benefits: The speed in accessing the server is dramatically improved.
Maintenance of ftpaccess is reduced.  The load on the system is
significantly lightened.  The modification has no side effects if you
never use the * notation for the user and group fields in ftpaccess,
so it shouldn't affect existing installations.

I'd like to submit these relatively simple code snippets to whoever
officially maintains wuftpd now, plus make them publicly available to
this list for scrutiny and/or further discussion.

So, here are two minor changes to extensions.c from the 2.4 sources.
The first replaces the expand_id() function with the following:

/* ------------------------------ cut here ------------------------------ */
void
expand_id(void)
{
    struct aclmember *entry = NULL;
    struct passwd *pwent;
    struct group *grent;
    char buf[BUFSIZ];

    while (getaclentry("upload", &entry) && ARG0 && ARG1 && ARG2 != NULL) {
        if (ARG3 && ARG4) {
	    if (*ARG3 != '*') {
		pwent = getpwnam(ARG3);
		if (pwent)  sprintf(buf, "%d", pwent->pw_uid);
		else        sprintf(buf, "%d", 0);
		ARG3 = (char *) malloc(strlen(buf) + 1);
		strcpy(ARG3, buf);
	    }
	    if (*ARG4 != '*') {
		grent = getgrnam(ARG4);
		if (grent)  sprintf(buf, "%d", grent->gr_gid);
		else        sprintf(buf, "%d", 0);
		ARG4 = (char *) malloc(strlen(buf) + 1);
		strcpy(ARG4, buf);
	    }
        }
    }
}
/* ------------------------------ cut here ------------------------------ */

The second involves the upl_check() function in extensions.c (with the
new code indicated) in the block that begins:

      /* if we did get matches... ..else don't do any of this stuff */
      if (match_value >= 0) {
          if (!strcasecmp(ap2, "yes")) {
/* ------------------------------ cut here ------------------------------ */
	      struct stat stbuf;
	      if ((ap3 && *ap3 == '*') || (ap4 && *ap4 == '*'))
	          stat(path, &stbuf);
	      if (ap3)
	          *uid = (*ap3 == '*') ? stbuf.st_uid : atoi(ap3);
	      if (ap4) {
	          *gid = (*ap4 == '*') ? stbuf.st_gid : atoi(ap4);
	          *valid = 1;
	      }
/* ------------------------------ cut here ------------------------------ */
              if (ap5)
                  sscanf(ap5, "%o", f_mode); /* the mode */
          } else {
              reply(553, "%s: Permission denied. (Upload)", name);
              return(-1);
          }
      } else {

...etc.

Your comments, and especially considering inclusion in the next
release, are appreciated.

--Morgan Davis

    ___ ____ ___ 
   /     /  /__   Network  |  Tel (619) 637-3637  |  Mail: [email-masked]
  /__   /  ___/  Services  |  Fax (619) 637-3630  |  WWW: http://www.cts.com

---

From: Thomas Leavitt <[email-masked]>
Date: Tue, 15 Nov 1994 13:36:39 -0800 (PST)

Ah! Thank you thank you thank you. I was considering the same
possibility and wondering how to address it. 

--
Web Communications (sm)            Thomas [email-masked]
Voice: (408) 457-9671              Lead Systems & Network Admin./Tech Suppt.
 
<a href="http://www.webcom.com/">Web Communications Home Page</a>