aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorTyler Hicks <tyhicks@linux.vnet.ibm.com>2009-04-16 18:35:37 -0500
committerTyler Hicks <tyhicks@linux.vnet.ibm.com>2009-04-22 17:02:46 -0500
commit3a6b42cadc112b01daf0525e5fcd90bb333a5bb3 (patch)
tree78cd37050a80e5c99eaa3ee97e20af834026c4d1 /include
parentca8e34f2b05a8289b47907b083dc01dd654ecbde (diff)
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>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions