"Christian Ambach" <b...@bashburg.de> writes: > I tried to salvage the volumes www and root.cell yesterday evening and > the salvager found some wrong vnodes.
> e.g. 07/14/2009 23:41:18 Vnode 133016: version < inode version; fixed (old > status) This is a normal message from salvage and usually doesn't imply much of anything. > Right after that, it worked as expected again but this morning it failed > again but with a slight change. > > In /afs/.<ourcell>, I now have a directory afs and under that the > complete AFS tree is accessible (having a directory afs again in the > cell root). One of the things that I'm having a hard time understanding about this bug report is where these things are happening. There's almost certainly a local cache consistency issue involved, which means that it's very important to know where exactly you're seeing these problems, whether that be in the FTP chroot, on the system running the ftpd but outside the chroot, or on a completely unrelated client. If you're seeing problems on a completely unrelated client, I don't think your problems are due to the chroot at all. It sounds instead like you have a corrupted root.cell. That seems to be the implication when you say that etch clients can see a loop as well. If this cell is public, it would be really helpful to know the actual cell name so that I can look at it directly. > Looks like I now have a loop in my filesystem like > /afs/.<ourcell>/afs/.<ourcell>/... > But it doesn't seem to be a mountpoint that I could remove > pm3:/afs/.<ourcell> # fs lsmount afs > 'afs' is not a mount point. Is pm3 the system that's running the ftpd? > Please note that etch clients are able to see that loop as well Including completely unrelated etch clients that aren't running ftpd and aren't doing chroot? >> Is the user able to cd out of the chroot, or is this only misleading >> output from getcwd? In other words, does cd /afs/.<ourcell> work at >> this point? > With this loop in place (unintentionally and unwanted) the FTP access > now works because the complete directory structure is available in the > chroot. What do you mean by "works"? That normally implies that it's functioning the way that you want it to, but I gather that's not the case? > I have to fix this as this is a security problem, we intentionally put > the users into a chroot so they cannot see the whole tree and how it is > exposed to them again :( Any ideas what has happened here and how to fix > it? Well, so far I don't have a clear picture of exactly what you're seeing. You seem to be having multiple unrelated problems at the same time, so I'm fairly confused. For example, salvaging of volumes has nothing at all to do with whether or not chroot into AFS works, nor do phantom mount points that are showing up on unrelated clients. -- 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
