tree 78cd37050a80e5c99eaa3ee97e20af834026c4d1
parent ca8e34f2b05a8289b47907b083dc01dd654ecbde
author Tyler Hicks <tyhicks@linux.vnet.ibm.com> 1239924937 -0500
committer Tyler Hicks <tyhicks@linux.vnet.ibm.com> 1240437766 -0500

eCryptfs: Larger buffer for encrypted symlink targets

When using filename encryption with eCryptfs, the value of the symlink
in the lower filesystem is encrypted and stored as a Tag 70 packet.
This results in a longer symlink target than if the target value wasn't
encrypted.

Users were reporting these messages in their syslog:

[ 45.653441] ecryptfs_parse_tag_70_packet: max_packet_size is [56]; real
packet size is [51]
[ 45.653444] ecryptfs_decode_and_decrypt_filename: Could not parse tag
70 packet from filename; copying through filename as-is

This was due to bufsiz, one the arguments in readlink(), being used to
when allocating the buffer passed to the lower inode's readlink().
That symlink target may be very large, but when decoded and decrypted,
could end up being smaller than bufsize.

To fix this, the buffer passed to the lower inode's readlink() will
always be PATH_MAX in size when filename encryption is enabled.  Any
necessary truncation occurs after the decoding and decrypting.

Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>