On Fri, Sep 12, 2003 at 10:03:46AM +0900, Stephen J. Turnbull wrote:
> >>>>> "Greg" == Greg Troxel <gdt_at_ir.bbn.com> writes:
> 
>     Greg> But if the constant or the data type changes the code will
>     Greg> be wrong and have a potential security issue.
> 
> I came to the same conclusion about some code in XEmacs recently.
> 
> Here I have to wonder if this warning doesn't expose a different bug,
> namely, that vdir->d_namlen is too small a type to detect a buffer
> overflow when it occurs!  (Logical possibility only, of course Jan
> would never permit such a thing!  ;-)

We have tests all over the place, both clients and servers do not allow
anyone to create filenames larger than this. I just checked and the only
place that was missing such a check in venus is where we convert from
the RVM directory format to the on-disk BSD format.

CODA_MAXNAMLEN is actually pretty strongly tied to the lowest common
denominator MAXNAMLEN for all platforms on which Coda is ported. So even
if some system at a future point allows longer filenames, we really
can't enlarge CODA_MAXNAMLEN or else that system can create files that
noone else can access or change.

The kernel is pretty paranoid about many things that venus passes down,
but considering that venus runs as root we are mostly protecting against
stupid programming mistakes. If someone passed down a seriously bad
directory file there are probably a lot more subtle things that can go
wrong. f.i. BSD readdir doesn't like directory entries that cross a disk
block (or was that a page boundary?).

The question really comes down to how much do we trust venus. If we
trust venus to do the right thing, then a lot of checks in the kernel
are superfluous. If venus is seriously untrusted we probably need even
more checks.

Removing this test is probably not that bad.

Jan