Subject: Upload file permissions....

From: Ted Keller <[email-masked]>
Date: Wed, 13 Jan 1999 14:55:57 -0500 (EST)

I'm running the wuftpd-2.4.2-beta-18 with the vr11 patches.  As I
configure the upload directories, I am getting confusing results.

If my upload record looks like....

upload /ftp/pm/testftp/pub /incoming yes keller pmtest 0640 dirs

and my /etc/passwd look like ....

testftp:x:1034:170:test ftp system:/ftp/pm/testftp/pub/./:/bin/true

everything works correctly.

However, if I have an upload record which looks like.....

upload /ftp/pm/testftp  /pub/incoming yes keller pmtest 0640 dirs

and a password entry which looks like

testftp:x:1034:170:test ftp system:/ftp/pm/testftp/./pub:/bin/true

uploaded files become owned by testftp instead of keller.

It would appear that, according to the ftpaccess man page, that both of
these configurations should work and assign ownership to the user keller.

What am I missing?

Many thanks.

ted keller - bfg.com

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 13 Jan 1999 20:48:07 -0500 (EST)

> everything works correctly.

This is how you should do it.  This upload clause will also work with the
passwd entry in your next attempt.

> uploaded files become owned by testftp instead of keller.

If you test, you'll find this upload isn't working at all.

> It would appear that, according to the ftpaccess man page, that both
> of these configurations should work and assign ownership to the user
> keller.

The man pages are quite confusing at points, this is one of them.

Back, years ago, guests where chroot'd to their home directories and there
was no /./ syntax for the passwd file home directory.  The man pages were
written at that time and the reference to 'root' was synonymous with
'home'.

With the addition of /./ to the passwd file two problems arose.  First,
the match wasn't against the 'root' part, it was against the 'home'.
Second, the upload clause needed to have /./ in it as well.

For a long time I'd been having trouble defining upload clauses which
worked.  If fact, it turned out that often the upload clauses weren't
being used and the only thing protecting my FTP sites was the Unix
permissions.

So, of course, I decided to try to fix things.  My first tests with the VR
patches were to believe 'root' as documented and test only against that
part.  Problem was, it broke the ability to have different upload clauses
for users with the same 'root' and different 'home's.

I re-thought the problem.  What's been happening was the /./ was in the
passwd file and not in the upload clause.  Easy enough to fix .. what the
VR patches do is pass both paths (the upload's 'root' and the directory
uploading to) through realpath() before comparing them.

Next problem.  If I had users with different 'root' but the same relative
'home' (the part after /./) the upload clause could not tell the
difference between them.  So I added the chroot path to the front of the
uploaded directory name.

Bernard, on behalf of the NEWVIRT folk, complained that the addition of
the chroot to the front of the path broke NEWVIRT virtual hosts, so I
added the absolute|relative|- option to allow you to choose.

--

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