Subject: Real users

From: Steve Szabo <[email-masked]>
Date: Thu, 20 Mar 1997 09:37:12 -0500 (EST)

How can I limit the access of real users to seem like they are
anonymous users?

Please someone get back to me!

==================================================================
| Steven Szabo                  +      2, 1st Canadian Place     |
| CoreLAN Communications Inc.   +      Suite 1730, Toronto, Ont. |
| Technical Support             +      Ph:  (416) 362-7378       |
| [email-masked]            +      Fax: (416) 362-8772       |
==================================================================

---

From: Michael Brennen <[email-masked]>
Date: Thu, 20 Mar 1997 08:48:26 -0600 (CST)

Guest users.  See the howto below.

   -- Michael

> How can I limit the access of real users to seem like they are

This is the location for the latest wu-ftpd.  You can't see the
directory contents, but get the file anyway.  It's there.

ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-13.tar.Z

wu-ftpd FAQ:  http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html
              OR
              send mail to [email-masked]
              with a subject line: send faq

guest howto:  ftp://ftp.fni.com/pub/wu-ftpd/guest-howto
              OR
              send mail to "[email-masked]"
              (immediate autoresponder; subject does not matter)

wu-ftpd list archive:  http://www.landfield.com/wu-ftpd/mail-archive/

There are additional security references in the above docs.

---

From: "frans stekelenburg" <[email-masked]>
Date: Thu, 20 Mar 1997 17:45:51 +0100

Hi,

In order to be able to SEE THE CONTENTS of a guest/anon. chrooted directory (ls 
actually giving a dir. listing, instead of a 'blind') on an IRIX system, the 
following information may help:

>               (immediate autoresponder; subject does not matter)

it may be a helpful addition?

Here it is:

=======================================================================
(ftp://ftp.fni.com/pub/wu-ftpd/guest-howto)
OS DEPENDENCIES / QUIRKS

<...>

IRIX (5.3, 6.x)

 (as in SUN 4.1.x, but without /dev/tcp)

Create a ~dev/zero device for the FTP directory as follows. (tip:
search on 'dev/zero' in your IRIX systems' Online Books.)
Run the following 'ls' command, then create the devices in the ~/dev
directory with the 'mknod' command, using the major and minor numbers
from the 'ls' results (thanks to Jim Davis <[email-masked]>).

ls -lL /dev/zero
cd dev
mknod zero c <major> <minor>
cd ..
chmod 555 dev

You may also wish to use the following method to create the device,
per Ian Willis <ianw.sco.com>; repeat this command for each device
(zero, tcp, etc.).

find /dev/zero -print | cpio -pd ~ftp

Also, you probably need the following shared libraries:
~lib/rld
~lib/libc.so.1
(found in /lib)

Also read the manpages on FTPD, or look in the IRIX Insight Library 
(Online Books) in the book/chapter "IRIX Admin: Networking and Mail"
for the paragraph 'How to Set Up a Proper Anonymous FTP Account'
(search helps:-)) on your IRIX system.

=======================================================================

-fs
[email-masked]

---

From: "frans stekelenburg" <[email-masked]>
Date: Thu, 20 Mar 1997 18:09:29 +0100

Hey

Hi,

Just got onto this list, but already have been digging trough some information 
pages searching for the following:

If a 'general' Anonymous ftp account is set up, and ~ftp will end up in
/my/local/ftp/files (passwd: ftp:*:777:777:ftp:/my/local/ftp/./:/bin/true), 
only the information under this tree (within ~ftp) are accessible.

BUT... in case a system has one ore more places on disk(s) that should be 
accessible for anonymous usages (obviously outside the ~ftp tree), this can't 
be done it seems.

Only HARDlinked _files_ seem usable, but this can't be done on directories.

Therefor I wonder if it wouldn't be nice to have an option in 'ftpaccess' where 
virtual extra_paths could be added?

Something like:
virtual /books /usr/local/bookshell/export
virtual /mags  /disk4/shared/magazine/files
...
(maybe with a guestgroup designation as 4th?)

If anyone has other suggestions, I like to hear them.
Grouping all under ~ftp, is not desired.

NOTE:
the PASSWORD FILE entry:

foobar:*:123:456:ftp:/my/users/foobar/./:/bin/true
----------------------------------- ^^^^

is INCOMPATIBLE with Netscape Ent./Ft.-Server if this user foobar should also 
be accessible through http://www.foo.bar/~foobar. Netscape Server refuses a '.' 
in the entry, amongst others.  Just FYI.

-fs
[email-masked]

---

From: "Karl O. Pinc" <[email-masked]>
Date: Thu, 20 Mar 1997 13:37:42 -0600

>virtual extra_paths could be added?

Can't see how to make this work.  Anonymous ftp chroot()s, so it _can't_
get to anything "above" it's new root.  This is for security reasons.

Karl

May the Legos (TM) always be swept from your path in the night.

---

From: Bob Luckin <[email-masked]>
Date: Thu, 20 Mar 97 14:42:36 CST

> get to anything "above" it's new root.  This is for security reasons.

Agreed.  There is an alternative, though...

You should be able to make a loopback mount for a directory which is
physically outside the ftp tree, to a mountpoint inside the tree.  It would
then appear to be under the tree...  We do this on our Solaris 2 system,
effectively putting additional "pub" directories (which are physicallly
on different disks to the one containing the FTP root) under our FTP tree.

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "Able was I ere I saw Waterloo"

---

From: [email-masked] (Koos van den Hout _U nix and we all_)
Date: Thu, 20 Mar 1997 22:24:24 +0100 (MET)

> virtual /mags  /disk4/shared/magazine/files

chroot is chroot. Really. It's not some feature of wu-ftpd, it's an integral
part of Unix security.

The only way to get what you want is loopback-mounts via loopback-filesystem
or via nfs.

> foobar:*:123:456:ftp:/my/users/foobar/./:/bin/true

File a bugreport with netscape.

						 KH

-- 
  Koos van den Hout,     Internetter, Unix freak, ISFJ and BBS SysOp at large
  [email-masked] (Work)  <-- finger -l for PGPkey      Fax: +31-30-2586290
  [email-masked] (Home)                      Workphone: +31-30-2586287
  http://www.cetis.hvu.nl/~koos/   Looking for a license plate with "RFC 822"

---

From: Michael Brennen <[email-masked]>
Date: Thu, 20 Mar 1997 17:37:35 -0600 (CST)

I have updated the guest howto with the following information for IRIX. 
Many thanks to Frans for supplying it. 

A few weeks ago I also updated the Sun information about allocating the
devices properly; a couple of list members contributed information to
round that out.  I lost the attributions somewhere, for which I apologize. 
If you recognize that you contributed something I'll be glad to add your
name to it. 

If you see additional information that would be useful either as
corrections to the overall document or for specific platforms I'll be glad
to add it.

   -- Michael

---

From: Jos Vos <[email-masked]>
Date: Fri, 21 Mar 1997 11:53:59 +0100

> Grouping all under ~ftp, is not desired.

A somewhat related remark/question, although not usable for this particular
problem:

Did anyone implement the correct handling of symlinks, so that for example
"cd" follows the "symlinked path" (like the shell built-in "cd" and "pwd"
commands do).  We once made a quick hack to wu-ftpd, which seemed to work
at first glance, and if there is general interest it would be nice if this
could be integrated in the official version.

On a large ftp-server we co-maintain, this feature is really needed: we have
divided the packages in a number of volumes (physical filesystems) and
the "logical" /pub tree only contains directories and symlinks to the
/vol/* trees (all relative symlinks, of course, so that they can be used
in a chroot environment).  We want the users to "stay in the /pub tree",
so that they not see the /vol/* stuff (they _may_ see it, but only if
they explicitly ask for).

Of course, we could also use loopback mounts or so, as described in one of
the other replies to the original problem, but this is not a nice solution
for this problem, if you have 100+ packages to maintain.

-- 
--    Jos Vos <[email-masked]>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204

---

From: [email-masked] (Koos van den Hout _U nix and we all_)
Date: Fri, 21 Mar 1997 12:17:25 +0100 (MET)

Quoting Jos Vos, who wrote :

> commands do).

wu-ftpd does not handle symlinks, Unix does. When I put a relative
symlink within ~ftp which points to another location within ~ftp it
will be followed.

So, according to the standards, wu-ftpd handles symlinks perfectly : it
ignores their presence and acts upon the item the link is pointing to.
The 'pointing to' is of course within the current process environment.
Which is different from a normal environment due to the chroot().

Again : chroot() is a Unix function, and does exactly what it is
supposed to, change the root dir of a process. Which means anything
outside that new root is unreachable.

Possible solutions : 

- mount your extra public disks within your ~ftp tree.

- set the homedir of ftp to /, which can have large security implications.

- or use disktools which create one large logical volume from all your
partitions, so you can move certain packages out of/into the ~ftp dir
with one mv command.

To translate it into normal English : you can't have your cake (a secure
chrooted environment) and eat it (symlinks outside that area) too.

					Koos van den Hout

---

From: Jos Vos <[email-masked]>
Date: Fri, 21 Mar 1997 13:14:21 +0100

> Which is different from a normal environment due to the chroot().

This I all know very well: I asked for something completely different.
Let's give a simple example:

-  symlink pub/linux -> ../vol/linux
-  vol/linux/... contains the real data

Now I have a ftp session:

	cd /pub/linux
	####### (1)
	cd ..
	####### (2)

At (1), the "pwd" command gives "/vol/linux" (like what /bin/pwd would
do using the UNIX shell), not "/pub/linux" (what the shell built-in pwd
would do).  

At (2), you are really in "/vol", not in "/pub", as I would like to see.

So, what I really asked for was to let wu-ftpd deal with symlinks like
the shell built-in commands do, so that "cd" and "pwd" act the same as a
(modern, symlink-aware) shell does.

Note that some clients, like Netscape, do this path interpretation at
the client site (but Netscsape doesn't let you explicitly do "pwd" or
"cd ..", but only displays the current directory and let you go "up
to higher level").  But I would like to see the server handle this.

> outside that new root is unreachable.

I know, I know... (I extensively make use of chroot environments for
webservers, sendmail, etc. in firewall configuration ;-)).

> chrooted environment) and eat it (symlinks outside that area) too.

That is not what I asked for: the original question had this requirement,
and I know this is impossible (without something like special mounts).

Hopefully this clarifies my question...

---

From: "frans stekelenburg" <[email-masked]>
Date: Fri, 21 Mar 1997 13:34:23 +0100

> chroot is chroot. Really. It's not some feature of wu-ftpd, it's an integral

thought so...

> The only way to get what you want is loopback-mounts via loopback-filesystem

Ahhh... why didn't I think of that earlier... nfs. Actually on this Irix 
system, NFS loopback links are not permitted according to it's Adm.Guide- but 
it links fine to an alias-name of the local system.

But please, can you explain the 'loopback-filesystem' concept? Or give the 
syntax?

> > is INCOMPATIBLE with Netscape Ent./Ft.-Server if this user foobar should
> > also be accessible through http://www.foo.bar/~foobar. Netscape Server
> > refuses a '.' in the entry, amongst others.  Just FYI.
> 

According to Netscape it's not a bug, but a feature. To circumvent a possible 
security breach, I've been told. So I figured it's helpful information.

Groetjes,

frans

---

From: "frans stekelenburg" <[email-masked]>
Date: Fri, 21 Mar 1997 13:51:58 +0100

On 21 Mar 97 at 11:53, Jos Vos wrote:

Jos,

Though I'm not quite sure why you are trying to establish...
 
> divided the packages in a number of volumes (physical filesystems) and the
> "logical" /pub tree only contains directories and symlinks to the /vol/* trees
> (all relative symlinks, of course, so that they can be used in a chroot
> environment).  We want the users to "stay in the /pub tree", so that they not
> see the /vol/* stuff (they _may_ see it, but only if they explicitly ask for).
> 
> Of course, we could also use loopback mounts or so, as described in one of the
> other replies to the original problem, but this is not a nice solution for
> this problem, if you have 100+ packages to maintain.

What if you have in {~ftp} (I'll use the {}'s to indicate a chrooted env.), a 
directory {~ftp/vol} which maybe a loopback link or real-path, that is only 
d--x--x--x (not readable, only accessible). That contains your 
packages/directories. 
And use in your 'ftpaccess' file the:

# cdpath
cdpath  /vol
cdpath  /

entries?

a {cd "foobar"} in {~ftp} will result in the client ending up in 
{~ftp/vol/foobar}. This option I found by accident working here, 'cause I 
wondered how one would end up in a subdir. that wasn't in the {~ftp}.

I hope I understood the casus correctly.

groetjes,
frans

---

From: Vincent Cojot <[email-masked]>
Date: Fri, 21 Mar 1997 09:25:08 -0500 (EST)

> But please, can you explain the 'loopback-filesystem' concept? Or give the 

Here is the procedure (it might be quite different in its syntax on your
IRIX box, the example being taken on a Linux box, but the concept is the
same ):

export your local filesystem:

raistlin@palanthas:[~]$ cat /etc/exports |grep dos
/dose/images            localhost(ro)

Verify the export:

raistlin@palanthas:[~]$ showmount -e palanthas |egrep "(Export|dos)"
Export list for palanthas:
/dose/images localhost

Create a directory to hold your export under your FTP home dir:

raistlin@palanthas:[~]$ ls -ld /home/ftp/pub/images                             
drwxrwxr-x  14 root     system      16384 May 24  1996
/home/ftp/pub/images

Then mount your export under your newly created dir:

raistlin@palanthas:[~]$ cat /etc/fstab |grep ftp
palanthas:/dose/images  /home/ftp/pub/images    nfs defaults    1 1

I hope this helps.

,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
Vincent S. Cojot, Computer Engineering. STEP project. _.,-*~'`^`'~*-,._.,-*~
Ecole Polytechnique de Montreal, Comite Micro-Informatique. _.,-*~'`^`'~*-,.
Linux Xview/OpenLook resources page _.,-*~'`^`'~*-,._ [email-masked]
http://www.info.polymtl.ca/~coyote  _.,-*~'`^`'~*-,._ [email-masked]

They cannot scare me with their empty spaces
Between stars - on stars where no human race is
I have it in me so much nearer home
To scare myself with my own desert places.       - Robert Frost

---

From: [email-masked] (Koos van den Hout _U nix and we all_)
Date: Fri, 21 Mar 1997 15:49:15 +0100 (MET)

> But please, can you explain the 'loopback-filesystem' concept? Or give the 

I have used it on Solaris, and I know it's available on Linux (kernel
option CONFIG_BLK_DEV_LOOP).

On Solaris, mounts look like :

# /sbin/mount -F lofs / /mnt
# /sbin/mount               
[..]
/mnt on / read/write on Fri Mar 21 15:42:09 1997
# /sbin/umount /

You'll have to check the manpages of other Unix versions to see if
loopback filesystem is available there.

				 Grtx KH

---

From: Michael Brennen <[email-masked]>
Date: Fri, 21 Mar 1997 10:10:55 -0600 (CST)

Koos is right; however, 'hard' links out of the chroot area, within the
same physical disk partition, do work.  I use this to link back to a
single instance of statically linked utilities (ls, etc.) outside the ftp
trees.  Just make sure you have the files owned and permissioned correctly
so they cannot be overwritten. 

   -- Michael

---

From: Jos Vos <[email-masked]>
Date: Fri, 21 Mar 1997 17:30:48 +0100

> I hope I understood the casus correctly.

I don't know whether you did, but I don't think your answer solves my
problem (I guess cdpath does a similar thing as the CDPATH environment
variable in most shells).

But take a look at ftp.nluug.nl (the system I'm talking about) with a
"normal" ftp client (that is, no Netscape or such), and do

	cd /pub/os/Linux/distr
	pwd
	cd RedHat
	pwd
	cd ..
	pwd

to see a "real-life" example of the problem I'm trying to explain.

Note:
	pub/os/Linux/distr
is a symlink to
	../../../../site/ftp.redhat.com/pub/redhat
which is a symlink to
	../../../vol/1/linux-redhat
All three (vol, site and pub) directory trees are accesible by the
user, but normally he only needs to use the pub hierarchy.
	
This makes the maintenance of all the stuff a lot simpler (the main
goal was to be able to easily move packages to other physical volumes),
and walking through the tree works fine in the shell, but not using
ftp :-(.

And, again, we did patch a previous wu-ftpd version to handle symlinks
"intelligently", that is, in the way shells handle them.  I'll try to
dig up our changes.

---

From: [email-masked]
Date: Thu, 12 Dec 1996 08:11:32 -0200

> on different disks to the one containing the FTP root) under our FTP tree.

Why modify the path of users for /home/users/./. I don't make this and
my
solution for chroot users work fine. However I have the problem. Some
users
have your home directory in other device, different of my ftp server.
How do I can make that this users also been chrooted. /dev must
hardlinked
with the ftp home directory.
Thank's in advance!

-- 
##############################################
## Rafael Vilarino Kuhn                     ##
## [email-masked]                       ##
## Gaucho por tradicao, Gremista de coracao ##
##############################################

---

From: [email-masked] (Koos van den Hout _U nix and we all_)
Date: Fri, 21 Mar 1997 23:45:23 +0100 (MET)

> "intelligently", that is, in the way shells handle them.  I'll try to

This is what is commonly called a getwd cache ?

For things like :

koos@idefix:~(504)$ cd anonftpdir/
koos@idefix:~/anonftpdir(505)$ pwd
/home/koos/anonftpdir
koos@idefix:~/anonftpdir(506)$ /bin/pwd
/ftp/ftp/pub/koos

I think your patches can be a welcome addition, maybe as a compile time
option. It's more of an interest to large sites like ftp.nluug.nl then
small sites.

						 Grtx KH