#11 forceFPTag security hole

[Tim Mann]

The repository should allow only vwizard to supply the
forceFPTag argument to insertFile and
insertImmutableDirectory. Supplying bogus values for
these can cause confusion -- the repository can be made
to think that two things have the same content when
they are really different.

This is a pretty obscure bug.

[Scott Venier]

Logged In: YES
user_id=291223

The forceFPTag argument could also just be totally removed
for SRPC clients.

[Kenneth C. Schalk]

Logged In: YES
user_id=304837
Originator: NO

A user recently tried using insertFile to copy an existing
immutableFile into a mutableDirectory. Their intent was to
make it possible to avoid the cost of copying such a file
through the NFS interface when it would later be collapsed
to use the same underlying file.

They were just passing a ShortId and left the forceFPTag
argument with the default value (NULL). This unfortunately
caused all such files to get the same fingerprint. (See the
code in VDirChangeable::insertFile which assigns the
fingerprint starting on line 950 of
repos/87/VDirChangeable.C; it will assign the fingerprint
nullFPTag in this case.) This caused all such files to be
collapsed to the same ShortId at vadvance time regardless of
contents. The solution was to pass the fingerprint of the
original file for the forceFPTag argument.

When we restrict forceFPTag, we should add an overloaded
version of insertFile that takes a VestaSource referring to
an existing immutableFile as an argument rather than a
ShortId. This would propagate both the shortid and the
fingerprint form the existing file to the new directory
entry. (It could even be a wrapper around the existing
insertFile.)

Note that insertImmutableDirectory does not have this
problem. It already takes a VestaSource as an argument and
will propagate the fingerprint of an existing immutable
directory to the new copy.