Christian Ambach <b...@bashburg.de> writes:
> I have fixed our root.cell so we can back to the original problem
> report. Sorry for the noise.
No problem.
I'm going to forward this along to the OpenAFS RT, since I'm not sure what
to make of this problem. Your suspicion that caching of paths to volumes
is happening may be correct. We've had problems with that in the past.
If you have a moment, you may want to consider trying the version of
openafs-client and openafs-modules-source (and a rebuilt module) from
backports.org. I have no idea if any changes in 1.4.10 from 1.4.7 will
fix this, though, so that may be a waste of time.
> 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?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
