Subject: How can guests share the /bin & /lib file?

From: Hanbing Yan <[email-masked]>
Date: Sun, 28 Mar 1999 23:16:25 -0500

I setup  a guest group of wu-ftp and use chroot. It works properly. But
I don't want every user has /home/userx/bin and /home/usrx/lib. Can
guest users share the /bin & /lib and at the same time they can't see
each other's file and directory?

Thanks
Hanbing

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 29 Mar 1999 08:04:39 -0500 (EST)

> each other's file and directory?

Yes.  The feature appeared in V16: restricted-uid/restricted-gid.  Of
course it had a bug (effecting IE and Netscape); the bug will be fixed
Thurday in VR17.

-- 

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

---

From: Hanbing Yan <[email-masked]>
Date: Mon, 29 Mar 1999 09:37:53 -0500

Thanks a lot.
Can you show me how to do that in details?

Hanbing

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 29 Mar 1999 11:16:32 -0500 (EST)

> > course it had a bug (effecting IE and Netscape); the bug will be fixed

This is full-on VR16/VR17 .. if you want to use it you *MUST* upgrade.

-- Caveats

I have the following local-site standards and recommend them to everyone:

 - All UID and GID < 100 are reserved for non-humans such as sendmail,
   apache and wu-ftpd.

 - All UID/GID >= 100 are normal users or one sort or another.

 - All UID/GID >= 100 have UID == default GID; although they may be
   members of other groups in /etc/group

 - All UID/GID >= 100 are FTP guests unless I say otherwise

 - All UID/GID >= 100 have homes in /home/users

 - This is a Linux system and all binaries are statically linked.  No PAM.
   That means we can run using the bare minimum.  YMMV on your system.

-- Example users

 - A few of the system accounts.
   root -- of course
        Root won't be allowed to FTP, but is listed because we want to
        always remember he's there and is a big security threat.

   ftp  -- the anonymous ftp user
        Even if you're not going to be allowing anonymous FTP, set up as
        if you will.  That way a mistake down the line doesn't give your
        successor a nasty surprise.  Besides, you might change you mind.

   ftpadmin -- the ftp server administrator
        I know a lot of people use rott to own and administer their FTP
        sites.  I cannot discourage that strongly enough.

 - A couple normal, Unix shell users.

   steve
       Steve called and wanted to be able to privately exchange files with
       some friends via anonymous FTP.  After some discussion, a private
       area of the base server was agreed upon.  BTW .. his friends think
       he's cool the way he's set up and he thinks he's got a great ISP
       'cause this took all of 30 seconds to set up when he asked for it.

   edie
       Steve's wife.  She does some web stuff using Frontpage's FTP
       wizard.

 - A software house who doesn't want a virtual host, but wants a password-
   protected area for their customers.  After discussion, it was
   determined that a single password for all customers was acceptable;
   their only goal was to keep non-customers out.

   swshop -- the software shop's Unix shell account
   swuser -- their guests

 - An agency who want a virtual host, with anonymous access, and a special
   password- protected area as well.  Again, one password for each guest.

   agency -- the agency's Unix shell account
   aguest -- their guests

 This email is long enough, I'll let you puzzle out the various passwd and
 group files and what should go in them.  The example site
 ( ftp://ftp.vr.net/pub/wu-ftpd/examples/ ) should help.

-- Filesystem layout

 - The anonymous FTP area has the following directories:

    /home/ftp
    /home/ftp/bin
    /home/ftp/dev
    /home/ftp/etc
    /home/ftp/incoming
    /home/ftp/private
    /home/ftp/private/ftpadmin
    /home/ftp/private/ftpadmin/incoming
    /home/ftp/private/steve
    /home/ftp/private/steve/incoming
    /home/ftp/pub

 - The user area has the following directories:

    /home/users
    /home/users/bin
    /home/users/dev
    /home/users/etc
    /home/users/steve
    /home/users/edie
    /home/users/swshop
    /home/users/agency

 - The software shop's guests are under the control of the shop

    /home/users/swshop/ftp
    /home/users/swshop/ftp/bin
    /home/users/swshop/ftp/dev
    /home/users/swshop/ftp/etc
    /home/users/swshop/ftp/incoming
    /home/users/swshop/ftp/private
    /home/users/swshop/ftp/pub

 - The agency's site and guests are under the control of the agency

    /home/users/agency/ftp
    /home/users/agency/ftp/bin
    /home/users/agency/ftp/dev
    /home/users/agency/ftp/etc
    /home/users/agency/ftp/incoming
    /home/users/agency/ftp/private
    /home/users/agency/ftp/pub

  This email is long enough, I'll let you puzzle out permissions.  The
  example site ( ftp://ftp.vr.net/pub/wu-ftpd/examples ) should help a lot
  with this.

-- IP layout

  FTP.example.com [10.0.1.1] -- the main, default FTP server

  FTP.agency.example.com [10.0.1.2] -- the virtual host for the agency

-- /etc/ftpaccess

loginfails 3

class user real,guest *
class anon anonymous  *

limit user 75 SaSu|Any1800-0600
limit user 35 Any
limit anon 35 Any
#
# 'user' class is usually via dialup so the limits are arbitrary
#
# 'anon' 35 is from expermentation on a 128K ISDN for a moderately busy
# site.  It allowed in enough users to not turn them away at peak times
# yet places a limit on total load in case something goes really wrong.

hostname ftp.example.com
email [email-masked]

virtual 10.0.1.2 root     /home/users/agency/ftp
virtual 10.0.1.2 banner   /home/users/agency/ftp-banner
virtual 10.0.1.2 hostname ftp.agency.example.com
virtual 10.0.1.2 email    [email-masked]
virtual 10.0.1.2 allow    agency
#
# By default, the server will only allow anonymous and guest access to the
# virtual host.  Guest access is only allowed if the chroot point for the
# guest is the same as the root for the virtual host: in this case, the
# user 'aguest'.  Our customer will pitch a fit if they cannot use their
# own site, so we need to specifically allow them in.

deny-uid %-99
deny-gid %-99
allow-uid ftp
allow-gid ftp
#
# I don't care what anyone else says .. don't let ANY users in with a UID
# or GID less than 100.  Of course, 'ftp' is in that range, so we need to
# specifically allow that user in or anonymous FTP won't work.
#
# Remember, the 100-limit is a Linux thing.  It's another value on some
# systems.  Take a look at your adduser script or /etc/passwd and see what
# it looks like you system uses.

guestuser *
realuser ftp
realuser ftpadmin
#
# Everyone is a guest.  Period.  Unless _I_, root, say otherwise.  The
# 'ftp' user is 'real' here (daemon oddity, sorry) otherwise anonymous FTP
# won't work.  And, for what it's worth, the ftpadmin is a real user.

restricted-uid *
unrestricted-uid ftpadmin
#
# All real/guest users are restricted to their homes.  Period.  Again,
# unless _I_, root, say otherwise.  ftpadmin is allowed to roam at will.

anonymous-root /home/ftp
#
# Forget /etc/passwd .. I want the anonymous FTP site rooted here.

guest-root /home/users
#
# Forget /etc/passwd .. all guests are rooted here.  With the following
# exceptions for customers' guest sites:
#
guest-root /home/users/swshop/ftp swuser
guest-root /home/users/agency/ftp aguest

message .welcome login
message .message cwd=*
readme  README*  cwd=*

compress        yes             *
tar             yes             *

private no

passwd-check rfc822 warn

log transfers real,anonymous,guest inbound,outbound 
log security real,anonymous,guest
log commands real,anonymous,guest
#
# If it's logable, log it.  Perl can deal with the mess later.
# Just don't forget to rotate the log files !!!

shutdown /etc/shutmsg

chmod		no		anonymous
delete		no		anonymous
overwrite	no		anonymous
rename		no		anonymous
umask		no		anonymous

autogroup ftponly local remote anon

path-filter anonymous,guest /etc/pathmsg ^[-A-Za-z0-9_\.]*$ ^\. ^-

upload /home/users/ftpadmin * no
upload /home/users/ftpadmin /tmp yes nodirs
upload /home/users/ftpadmin /home/users/ftpadmin yes
upload /home/users/ftpadmin /home/users/ftpadmin/* yes
upload /home/users/ftpadmin /home/ftp/ftpadmin yes ftpadmin ftpadmin 440 nodirs
upload /home/users/ftpadmin /home/ftp/private/*/incoming yes * * 440 nodirs
#
# I like to restrict the ftpadmin to only being able to upload into his
# own home directory, the anonymous area, and the system tmp directory.

upload /home/ftp * no
upload /home/ftp /incoming yes ftpadmin ftpadmin 440 nodirs
upload /home/ftp /private/*/incoming yes * * 440 nodirs
#
# Anonymous users can upload only into the anonymous area.

upload /home/users/swshop/ftp * no
upload /home/users/swshop/ftp /incoming yes swshop swuser 400 nodirs
#
# Guest users of the software shop's can only upload into the incoming
# area.

upload /home/users/agency/ftp * no
upload /home/users/agency/ftp /incoming yes agency aguest 400 nodirs
#
# Anonymous and guest users of the agency can only upload into the
# incoming area.

upload /home/users/* / no
upload /home/users/* /bin no
upload /home/users/* /bin/* no
upload /home/users/* /etc no
upload /home/users/* /etc/* no
upload /home/users/* /dev no
upload /home/users/* /dev/* no
upload /home/users/* /swshop/ftp/bin no
upload /home/users/* /swshop/ftp/bin/* no
upload /home/users/* /swshop/ftp/etc no
upload /home/users/* /swshop/ftp/etc/* no
upload /home/users/* /swshop/dev no
upload /home/users/* /swshop/dev/* no
upload /home/users/* /agency/ftp/bin no
upload /home/users/* /agency/ftp/bin/* no
upload /home/users/* /agency/ftp/etc no
upload /home/users/* /agency/ftp/etc/* no
upload /home/users/* /agency/dev no
upload /home/users/* /agecny/dev/* no
#
# All users (including ftpadmin and the guests of our customers) are
# specifically prevented from uploading into any of the areas needed to
# make the ftp site work.

noretrieve core
noretrieve .notar
noretrieve .forward
noretrieve .rhosts
noretrieve /dev/
noretrieve /proc/
noretrieve /lost+found/
noretrieve /home/ftp/bin/
noretrieve /home/ftp/etc/
noretrieve /home/ftp/dev/
noretrieve /home/ftp/lost+found/
noretrieve /home/users/bin/
noretrieve /home/users/etc/
noretrieve /home/users/dev/
noretrieve /home/users/lost+found/
noretrieve /home/users/swshop/ftp/bin/ 
noretrieve /home/users/swshop/ftp/etc/
noretrieve /home/users/swshop/ftp/dev/
noretrieve /home/users/swshop/ftp/lost+found/
noretrieve /home/users/agency/ftp/bin/
noretrieve /home/users/agency/ftp/etc/
noretrieve /home/users/agency/ftp/dev/
noretrieve /home/users/agency/ftp/lost+found/
#
# Don't let *ANYONE* grab copies of any of these files or any files in
# these directories.  Period.

--

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 29 Mar 1999 12:00:52 -0500 (EST)

A brief comment about shutdown, and oops, a line crept in from my live
ftpaccess ... and a rant about 'ftponly'

> shutdown /etc/shutmsg

This is problematic.  I never shutdown my FTP server using ftpshut so I've
never fixed it.  The problem is this: to work for all virtual hosts, guest
and anonymous users, the file '/etc/shutdown' needs to be visible from
every one of those chroot'd areas.

My recommendation: if you must shut down the server, do it via inetd or by
killing the standalone daemon.  Users will get the hint when the
connection is refused.

Someday, I promise, I'll get arround to fixing the 'shutdown' feature so
it's actually usable by mere mortal system administrators.

> autogroup ftponly local remote anon

For the site I'm discussing, this should read:

autogroup ftponly user anon

-- 

This use of the group 'ftponly' and the idea of FTP-only users (who cannot
use Telnet/shell) is the source of great confusion.

Membership in the group 'ftponly' does *NOT* mean the user cannot use
telnet/shell.

The idea is there are files which you want *ANONYMOUS* FTP users to be
able to see but which you do not want telnet/shell users looking at.  
Message and readme files, for instance, might fall in that category.

A number of documents, including the FAQ, suggest creating a special shell
and adding it to /etc/shells so FTP-only users (who cannot use
telnet/shell) are properly adminished.  This shell s typically called
/bin/ftponly.  It is NOT related to the 'ftponly' group.

I class users in three ways here, and I don't bother with /bin/ftponly as
a shell:

Normal users, who can use telnet/shell are given a real shell from
/etc/shells (this is Linux, so it's usually /bin/bash).

FTP-only users, who can NOT use telnet/shell are given a fake shell from
/etc/shells of /bin/false.  This causes a telnet/shell session to
immedeately terminate.  Since it is listed in /etc/shells, they are
allowed to use FTP.  Since most of my users are guests, and virtually all
of them use PPP dialups and don't know about or want telnet access, this
is the default shell on my server.

Non-FTP users (ie., Frontpage web sites and many of the adminstrative
accounts like 'mail' for sendmail) don't want to be allowed in via any
means: FTP, telnet or shell.  For those users I set the shell to
/bin/true which is NOT listed in /etc/shells.  This is a backstop to the
deny-uid/deny-gid ftpaccess clause which should have kept the users out
before we even look at their shell.

A posting on Bugtraq last night indicated a user had problems with the use
of /bin/ftponly .. it is my opinion that he suffers from the confusion
between the oft-used example group 'ftponly' and the concept of FTP-only
users.

-- 

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