Hi Russ,
I have fixed our root.cell so we can back to the original problem report. Sorry
for the noise.
Let me try to describe it in another way:
we chroot() FTP users into our root.cell.
Under that, several volumes are mounted. For one particular volume, FTP access in the chroot does not work correctly,
because getcwd() returns the absolute path to the FTP daemon instead of the path relative to the chroot as it is in the
other volumes.
The bad volume is the "www" one, here are some traces of the FTP daemon
pm3:~# strace -ff -p 3574 2>&1|grep cwd
[pid 23701] getcwd("/"..., 4096) = 2
[pid 23701] getcwd("/"..., 4096) = 2
[pid 23701] getcwd("/upload"..., 4096) = 8
[pid 23701] getcwd("/afs/.<ourcell>/www"..., 4096) = 24
[pid 23701] getcwd("/afs/.<ourcell>/www"..., 4096) = 24
The bad getcwd output leads to the FTP server reporting to the user that he is now in the absolute path (but that does
not exist because we are in the chroot). So if you are using a graphical client like FileZilla, it will report that you
are now in /afs/.<ourcell>/www instead of just /www and all links to subdirectories in the FTP client are broken.
So there has to be something special about that volume and I suspect it is that only in this volume other processes like
apache are opening files and maybe doing getcwd() calls too.
It is possible that the AFS client caches the result of a getcwd() call or something similar for all processes and does
not take chrooted processes into account?
Is there anything else I can provide to you for debugging purposes?
Cheers,
Christian
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
