Subject: Re: FFS reliability problems
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 06/08/2002 12:39:35
>>> When I was playing guessing the NFS handle for the filesystem root
>>> was trivial - inode 2, use count 1 (or similar).
>> If fsirand has not been run on the filesystem, yes.
> I'm not sure the systems I was using had a fsirand...

Ugh.  Having an NFS server without something akin to fsirand is a
pretty major security lose.  (Not that NFS is any paragon of security,
but without making filehandles hard to guess it is, as you found, even
more trivial to break into.)

> It is also a 'cludge' for broken fs code - since the actual fix is to
> allocate 'random' 'use count' values.

Oddly enough, allocating "random" use-count values is exactly what
fsirand does.

> ([...]  I fixed the fs code to use random numbers - so any old NFS
> file handle was extremely likely to be invalid after a server reboot.
> Unfortunately that lead to a hard retry loop and required the client
> to be reloaded....)

Well, yes.  NFS is supposed to be stateless; you are supposed to design
your file handles in such a way that their validity survives anything
that commonly happens to your server - or at least, anything that
commonly happens to your server that you don't want clients to have to
remount the filesystem because of.  Reboots are probably the commonest
example.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B