Subject: [923] Guest ftp access

From: [email-masked]
Date: Wed, 14 Dec 1994 14:55:16 -0800 (PST)

A couple of recent inquiries to this list regarding guest access prompted me 
to finish a project along those lines that I had thought to do for some time 
as part of administering an inhouse-only anonymous ftp server.  I wanted to 
have a directory tree available to all anonymous ftp users, but with 
individual directory maintenance done by designated persons with a real ftp 
login that was limited in access to that one subbranch of the tree.  The 
anonymous users could then still only upload to 'incoming', but they could 
read the whole subtree, and maintenance of specific subtrees could be farmed 
out to various departments.  This is how I did it.  It almost worked, and I 
don't understand why it didn't work.  (FYI my OS is LynxOS, a realtime unix 
implementation.)  I know this will take a bit of time to understand - thanks 
in advance for your patience.

/etc/ftpaccess is as follows (generally very close to ftpaccess.heavy):

class local  real, guest, anonymous    xxx.xxx.xxx.xxx
    . . .
path-filter  guest  /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-
    . . .
guestgroup clients

/etc/group file has these groups defined:

anon::300:ftp                             # for anonymous ftp
clients::400:client1,client2              # for tree maintenance

/etc/passwd has these entries:

ftp::3:300::/Public/ftp:/bin/sh                        # for anonymous ftp
client1:<pwd>:1:400::/Public/ftp/pub/./win3:/bin/sh    # for windows maint
client2:<pwd>:2:400::/Public/ftp/pub/./unix:/bin/sh    # for unix maint

The anonymous user logs into /Public/ftp as root and can access the contents 
of the win3 and unix subdirectories.  The win3 and unix directories are owned 
as follows:

            Owner:   Group:     Directory:
drwxr-xr-x  client1  clients    win3
drwxr-xr-x  client2  clients    unix

client1 _should_ be able to ftp to .../win3 as root and can do full 
maintenance to the directory, renaming deleting and uploading files as needed. 
client2 _should_ be able to do the same to the .../unix directory.  However, 
with guestgroup set as clients, nothing in the directory is visible, though 
there are files there that are fully owned with mode 664 by the accessing 
client.  Upload is possible (with upload provisions allowed by ftpaccess), but 
the files disappear and cannot be seen.

As I understand guestgroup this should work.  If I change guestgroup to some 
group other than clients, then client1 and client2 can access the directory 
and see all the files, but they can also walk back up the tree, which I don't 
want them to be able to do.  So, things are close but not there; if someone 
has an idea why I certainly appreciate the help.

---------------
Michael Brennen                    Intecom, Inc.
[email-masked]               5057 Keller Springs
(214) 447-8074                     Dallas,  TX  75248

---

From: [email-masked]
Date: Fri, 16 Dec 1994 14:02:09 -0800 (PST)

After working with this a while I finally came up with the answer in my sleep 
last night.  It seems so obvious in retrospect...

When the guest user logs in, a chroot() is done to the appropriate 
subdirectory - since that is the new root, there are no longer any executables 
in the path, so ls could not be executed to show the contents of the 
directory.  I fixed this the only way I know how - I put a bin directory with 
ls in it in the guest ftp login directory, protection 555 on bin and 111 on ls 
so it can't be modified.  That fixed the problem.  I don't like having to copy 
ls multiple times, but I don't know any other way around the problem.  I may 
play with links and see if that works.

I hope this has been useful to someone else...

---

From: "Randolph J. Herber" <[email-masked]>
Date: Fri, 16 Dec 94 17:52:10 -0600

|Date: Fri, 16 Dec 1994 15:00:55 -0800 (PST)
|From: [email-masked] (Bill Campbell)
|Subject: [946] Re: [945] Re:  [943] RE: [923] Guest ftp access
|To: [email-masked]
|Cc: [email-masked]

|> Hard links will work.  Soft (or symbolic) links will not.
|> Hard links indicate inode numbers directly.  Soft links supply different
|> translations for path components.

|> Symbolic links must be relative (i.e. not starting with a / if they are
|> to work both in and out of the chroot environment.  Think about the
|> meaning of an absolute (i.e. beginning with a /) link in both environments.
|> To work properly a symbolic link must not attempt to escape the chroot
|> environment.

|One way around this that works is to make directories in the root
|file system that are symlinks to the ftp file system.  For instance,
|we have our ftp stuff under the /ftp directory (original huh?).  Then
|I have linked 'ln -s /ftp/pub /pub' so that a symlink under anon-ftp
|will resolve properly when running on the normal system.  I find this
|a lot easier than trying to figure out relative path names on our
|system where there are multiple file systems under the /ftp directory
|which precludes using hard links.

I agree that this works.  It works because the /ftp/pub directory is in
the ftp area.  But, I can give you a case where your absolute link will
fail:

	(This mode is easy to do for some UNIX variants that have
	 a maintenance mode that is resident in either the swap area
	 or on some other device than the normal boot partition):

	On SGIs, for example, in miniroot mode, the normal root filesystem
	is mounted on /root and resides in what is normally the boot
	disks' swap partition.  That absolute soft link would attempt
	to link to a directory in the miniroot system.

I find it easiest to make relative symbolic links correctly
by changing current working directory to the directory to the
directory where the symbolic link is to be made, and making the
symbolic link there:

	cd /
	ln -s ftp/pub pub
	
	(I remember the argument as be the same as if I were moving the
	directory to a new location.  This is reasonable because on most
	systems, cp, ln, and mv are the same executable.)

Notice that neither argument has a leading /.

Sometimes, .. components are needed (a made-up example):

	cd /usr
	ln -s ../var/share/man man

|Bill

|INTERNET:  [email-masked]   Bill Campbell; Celestial Systems, Inc.
|UUCP:              camco!bill   2835 82nd Avenue S.E. S-100
|FAX:           (206) 232-9186   Mercer Island, WA 98040; (206) 947-5591
|http://www.celestial.com/

|The question is, why are politicians so eager to be president?  What is
|it about the job that makes it worth revealing, on national television,
|that you have the ethical standards of a slime-coated piece of
|industrial waste?
|		-- Dave Barry, "On Presidential Politics"

Randolph J. Herber, [email-masked], +1 708 840 2966, CD/HQ
(Speaking for myself and not for US, US DOE, FNAL nor URA.)
(Product, trade, or service marks herein belong to their respective owners.)