On 6/16/06, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
Did you reboot the nfs server while clients had the fs mounted? Or
stoped the nfsd and run fsck or a resize? Anything that could change
the inode numbers without the clients getting any notice?
Yes, we rebooted and recreated the filesystem from a backup.
We suspect that the inode numbers must have changed.
I noticed this and can reproduce it by running exportfs -u, umount,
resize2fs, mount, exportfs and then accessing some previously used
file on the nfs clients. The client (or server?) still has the old
inode numbers cached and directly access the inodes while the
resize2fs has removed it. The ext2-fs gives an error and remounts it
read-only.
That's interesting, didn't think it was so easy to reproduce -
have to try that.
Does it also remount the filesystem read-only when mounted
with the errors=continue mount option?
I even have fears that this is caused solely by the client caching the
inode for the file. If that is the case then a malicious client could
send requests for faked inodes causing ext2-fs errors on the server
and forcing the nfs share into read-only mode. An ugly DOS attack.
Yes, that's what i think as well.
Regards,
Peter