Subject: guestgroup chroot()/chdir() problems

From: [email-masked]
Date: Fri, 17 Mar 1995 09:40:39 -0800 (PST)

Routinely checking my logs yesterday I saw that an authorized guestgroup user had popped up 
one level above what should have been his chroot()ed directory; I quickly checked the 
password file, and I had set up the guest accounts as given in the docs that come with 
wu-ftpd:

user:*:123:456:User Acount:/home/dir/./user:/etc/ftponly

What I saw was that the user had gone up into the 'dir' directory and had entered other 
guest accounts.  No damage was done, as there isn't much there yet, but needless to say I 
quickly changed to the following:

user:*:123:456:User Acount:/home/dir/user/./:/etc/ftponly

That fixed the problem.  I am sure I checked this out, but I must have been asleep at the 
switch.  When logged in as in the first example, the current directory even showed as 
"/user", so the warning was clear that all was not as it should be.

I am running Linux 1.1.94; there may be something OS dependent about this, because it must 
work as defined in the docs for somebody somewhere, or it wouldn't have been written that 
way.  So, if you are depending on chroot()/chdir(), check this out *carefully* on your 
system. 

Has anyone else seen this?  Does it work for anyone as defined in the docs (first case 
above)?

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

---

From: Thomas Leavitt <[email-masked]>
Date: Fri, 17 Mar 1995 21:27:46 PST

Michael,

 I think you've misinterpreted the mechanism:

 /users/ftp/./pub/userid (to take an example from our system),
 places the user in their home directory "/pub/userid", but allows them
 to "cd" up to "pub", and "/" (which happens to be the "ftp" directory).

 To take your example, /home/dir/./user/ would place them in "/user", and
 allow them to cd to "/" (which would be "dir")...

 No security violation here, although this mechanism unfortunately causes
 Netsite WWW Servers to not be able to access a user directory, because
 they refuse to accept "." or ".." in the path to a directory for
 security reasons (I see the rationale for the latter, but not for the
 former).

Sincerely,
Thomas Leavitt

--
Web Communications (sm)            Thomas [email-masked]
Voice: (408) 457-9671 x101         Lead Systems & Network Admin./Tech Suppt.
 
Web Communications Home Page <URL:http://www.webcom.com/>

---

From: [email-masked] (Tom Lojewski)
Date: Mon, 20 Mar 1995 10:07:42 -0800 (PST)

>  security reasons (I see the rationale for the latter, but not for the

Assuming by "former" you mean the mechanism that has "guest" users
sharing the same "chroot()'ed" root directory (/home/dir in the above
example):

The reason is so all guest users can share the same /usr, /bin, /etc
and /dev sub-trees.  And if you have your anonymous users chroot() to
a directory below this (/home/dir/anonymous) then you can build links
like:

            /home/dir/etc -> /home/dir/anonymous/etc

And you only have to maintain one set of ancillary directories.

--------------------------------------------------------------------------
Tom Lojewski  -  ACUSON Corp  -  Mountain View, CA - ([email-masked])