Several AFSVol* RPCs are defined with an unbounded XDR "string" as
input.
RPCs with unbounded arrays as inputs are susceptible to remote
denial-of-service (DOS) attacks. A malicious client may submit an
AFSVol* request with an arbitrarily large string, forcing the volserver
to expend large amounts of network bandwidth, cpu cycles, and heap
memory to unmarshal the input.
Instead, give each input "string" an appropriate size.
Volume names are inherently capped to 32 octets (including trailing NUL)
by the protocol, but there is less clearly a hard limit on partition names.
The Vol_PartitionInfo{,64} functions accept a partition name as input and
also return a partition name in the output structure; the output values
have wire-protocol limits, so larger values could not be retrieved by clients,
but for denial-of-service purposes, a more generic PATH_MAX-like value seems
appropriate. We have several varying sources of such a limit in the tree, but
pick 4k as the least-restrictive.
[kaduk@mit.edu: use a larger limit for pathnames and expand on PATH_MAX in
commit message]
Change-Id: Iea4b24d1bb3570d4c422dd0c3247cd38cdbf4bab
proc CreateVolume(
IN afs_int32 partition,
- string name<>,
+ string name<VNAMESIZE>,
IN afs_int32 type,
IN afs_uint32 parent,
INOUT afs_uint32 *volid,
IN afs_int32 trans,
IN afs_uint32 purgeVol,
IN afs_int32 newType,
- IN string newName<>,
+ IN string newName<VNAMESIZE>,
INOUT afs_uint32 *newVol
) = VOLCLONE;
) = VOLGETSTATUS;
proc SignalRestore(
- IN string name<>,
+ IN string name<VNAMESIZE>,
int type,
afs_uint32 pid,
afs_uint32 cloneid
proc SetIdsTypes(
IN afs_int32 tId,
- string name<>,
+ string name<VNAMESIZE>,
afs_int32 type,
afs_uint32 pId,
afs_uint32 cloneId,
) = VOLMONITOR;
proc PartitionInfo(
- IN string name<>,
+ IN string name<4096>,
OUT struct diskPartition *partition
) = VOLDISKPART;
) split = VOLDUMPV2;
proc PartitionInfo64(
- IN string name<>,
+ IN string name<4096>,
OUT struct diskPartition64 *partition
) = VOLDISKPART64;