From owner-freebsd-questions Wed May 15 13:44:32 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA20765 for questions-outgoing; Wed, 15 May 1996 13:44:32 -0700 (PDT) Received: from mistery.mcafee.com (jimd@mistery.mcafee.com [192.187.128.69]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA20759; Wed, 15 May 1996 13:44:28 -0700 (PDT) Received: (from jimd@localhost) by mistery.mcafee.com (8.6.11/8.6.9) id NAA30684; Wed, 15 May 1996 13:52:51 -0700 From: Jim Dennis Message-Id: <199605152052.NAA30684@mistery.mcafee.com> Subject: Re: Setting up user accounts but with no email access To: paul@riker.comcirc.com.au (Paul Sondhu) Date: Wed, 15 May 1996 13:52:50 -0700 (PDT) Cc: freebsd-questions@freebsd.org, questions@freebsd.org In-Reply-To: from "Paul Sondhu" at May 14, 96 10:13:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I am setting up a few user accounts on our WWW server so that users can > FTP to the server to post up their web pages into their relevant > web page directories. > > How can I disable email access for these users. ie. I dont want them > to have an email account, only an account to FTP files to. > > The users cannot telnet into our server since I have not given them > read or execute permission to the default shell ( tcsh ) so they cant > log onto the machine and use pine, elm, etc. > > At the moment they can use a pop client since a pop server is running on > the machine. I dont want to remove the popper daemon since there are > a few accounts on there who need pop email access. > > Any help would be greatly appreciated. > > Paul. Paul, In my other message I suggested procmail as a way to bounce the mail for any of these users. I didn't notice that you were trying to accomplish ftp access. I would suggest that you use wu-ftp, create a group for these 'ftp-only' accounts, and use the wu-ftp "guestgroup" directive (in the ftpaccess file). 'man 5 ftpaccess' (after you've installed the wu-ftp port). The problem with allowing "normal" user account "non-shell" access to the machine is that a creative user (or a half-wit hacker *posing* as a valid user) can subvert ftp only access to their home directory into arbitrary shell commands ('put .forward' where .forward = "|/where/ever/some.command" is just one example of this). My suggestion allows you to run all of these accounts such that they are switched to a chroot'ed environment. You can then set the permissions for their "ftphome" directory to prevent access by other members of that group. This works something like: / : true root /export/home : system home directories /export/home/.nomail : true home for all ftp-only accounts /export/home/./.nomail/.ftp-only : chroot for ftp-only guestgroup /export/home/./.nomail/.ftp-only/foo : ftp-only user "foo"'s "ftphome" In the /etc/passwd file you can use the following syntactical "trick" to tell wu-ftp where to set the initial directory for a given user (member of a guestgroup): foo:*:1000:42:Foo's Account:/home/export/.nomail/./ftp-only/foo:/usr/bin/passwd ^^^^^^^^^ Note the '/./' embedded in the "home directory" field With some carefull arrangement of ownership and permissions is should be possible to get all of this to jive. Frankly I haven't had to set something like this up so I'm not sure of all the details. I give plenty of accounts which are ftp/POP only (no normal shell). However all of those people (employees) can simply ask for shell access on that system. Thus I don't have to be concerned about the security considerations of those accounts (their for internal access only -- behind a set of packet filters and all that). (Perhaps I should say that I have the same considerations for those accounts as I do for the shell accounts). Hope all of that helps. I figure I might have to actually set something like this up for real someday -- which is why I decided to field this question. Jim Dennis, System Administrator, McAfee Associates