Subject: Please help...

From: Mad Vinnie <[email-masked]>
Date: Wed, 26 May 1999 13:05:25 +0200

Hi,

I know this may sound funny, but it is the first time I need to put up a
multiuser site. I only have some experience with a single user site
(just anon access) but now I need for 200 users to have their own
homepage and be able to upload them to a server, the server is running
Suse 6.1 and the latest wu-ftp (2.5.0 I believe).

I need them to be able to view/upload files to their own dir. but not to
view anyone else dir. at this point they can look at eachothers dir and
stuff (hell, the can even go to the root dir.) Can anyone give a some
hints on where I should start, I don;t seem to understand yet what I do
wrong (little experience...)

Thanks in advance,

Greetz Vincent...

:-))

---

From: Ted Keller <[email-masked]>
Date: Wed, 26 May 1999 09:24:45 -0400 (EDT)

Mad,

Read the part about guest users (guestgruop).  Note, you will have to
create a small change rooted environement for eacy one - but once it is
set up correctly, each "users" will be able to maintain their own area -
and not be able to see anywhere else in the system.

Let me know if you need more help.

ted keller

---

From: Mad Vinnie <[email-masked]>
Date: Wed, 26 May 1999 18:08:23 +0200

First of all, thanks for all the replies.

I've think (almost sure) I've done all that the FAQ says about the guest
accounts (ftp.fni.com/pub/wu-ftpd/guest-howto). But now when I try to
logon via FTP it says error 530 Login incorrect. When I change the shell
back to /bin/bash I can login again but then I can login via telnet and
view all the dir's up to the root.

I'm not sure what I'm doing wrong.

I started out with wu-ftpd 2.5.0 but then gone back to Stan Barbers'
version (2.4.2 because it was recommended (highly) in the FAQ. but still
it doesnt' work. I use the ftponly shell etc, but it don't seem to get
going.

Anyone have any idea's.

On Wed, 26 May 1999 09:24:45 -0400 (EDT)

---

From: Ted Keller <[email-masked]>
Date: Wed, 26 May 1999 12:32:06 -0400 (EDT)

Mad,

You probably now need to add your shells to the /etc/shells file.  If it
doesn't exist, create it.

Normal shells to be there....

/bin/true
/bin/csh          (for real users)

If your using bash - add it also.  (make the pathnames match the location
of these shells for your box).

ted keller

---

From: Mad Vinnie <[email-masked]>
Date: Wed, 26 May 1999 18:53:22 +0200

On Wed, 26 May 1999 12:32:06 -0400 (EDT)

> /bin/csh          (for real users)

Someone else came with the same idea, but I already have done that (it
says so in the FAQ). But the fake shell works great for telnet , but not
for the ftp. When I try to telnet it kick's me out just as it's supposed
to do. but when I try to ftp it denies my login.  When I change it back
to /bin/bash it works just fine for ftp but not for telnet.

Greetz Vincent...

:-))

---

From: "Ian Guthrie" <[email-masked]>
Date: Wed, 26 May 1999 12:53:45 -0400

If you are having problems with the shells you could always just put "exit"
and nothing else in the user's profile so they can't login via shell. That
way, you don't have to worry about what shell they are using or configuring
the shells portion of WU-FTP. . .

Any comments anyone else?

Ian

---

From: Mad Vinnie <[email-masked]>
Date: Wed, 26 May 1999 19:24:19 +0200

On Wed, 26 May 1999 12:53:45 -0400

> Any comments anyone else?
The problem is when I don't use a 'legitimate' shell I can't login via
ftp. 

Any idea's???

Greetz Vincent...

:-))

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 26 May 1999 14:00:26 -0400 (EDT)

> The problem is when I don't use a 'legitimate' shell I can't login via

If you're using Redhat, and have PAM enabled, these rules may be applied
slightly differently: PAM does its own check of the /etc/shells file and
the daemon's check is disabled.

In the base daemon, the /etc/shells check is done by the OS runtime
function getusershell().  I would assume that that function needs to have
read access to the file /etc/shells, so check that the file is world-
readable.

Some systems do not normally have /etc/shells and the getusershell()
function.  For those systems, the daemon uses it's own version from the
support directory.

It would not surpise me to learn there are:

 - systems which cache the /etc/shells file internally to make
   getusershell() faster.  This caching could be getting in your way.  If
   yours is such a system you'll need to flush the cache when you change
   the file.

 - systems which provide getusershell() which does not use /etc/shells.
   If your system is such, you'l need to either switch the daemon to use
   the version from support, or you'll need to read the manuals to
   determine how to manage the list of valid shells.

 - systems whose getusershell() function makes additional checks, for
   instance that the named shell exists and is executable.  If your system
   is such, you'll need to determine the rules and make sure your
   replacement shell meets them.

In general, however I'd suggest you try the following:

Create a file named /bin/ftponly containing the following:
#!/bin/sh
exit(0)

Set the ownership and permissions on the new shell program.  Check how
other shells are set, but on most systems, the following will do:
chown 0 /bin/ftponly
chgrp 0 /bin/ftponly
chmod 755 /bin/ftponly

Add the following line to your /etc/shells:
/bin/ftponly

Verify that the user is not named in /etc/ftpusers.

Try your telnet and ftp tests again.

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: "Ian Guthrie" <[email-masked]>
Date: Wed, 26 May 1999 13:57:24 -0400

Use a legitimate shell, just put "exit" as the ONLY line in the users
".profile"

That way, they technically actually log in for a millisecond but the first
thing that happens is they are dropped out of the shell.

Just one option. Comments anyone?

Ian