Don't use faccessat(AT_SYMLINK_NOFOLLOW). In Android, AT_SYMLINK_NOFOLLOW
is ignored. In glibc, it returns counter intuitive results when a
symbolic link is encountered, returning true all the time even though
an open(O_NOFOLLOW) will eventually fail.
Instead, stat the file and check to see if it's a regular file,
not a directory or symlink or some other weirdness.
In addition, fix a bug where isAsecInDirectory would return
true ("-1") if the asec directory didn't exist. It should return
false.
Bug: 18867827
Change-Id: I33d90e9095fad36ce0f83fde105b70f72e4eaef4
The strncpy operation does not write a 0 termination
if the name is larger than the target buffer.
Ensure that zero termination is always written using
safe strlcpy function.
Change-Id: Idb68cdff7cd1a860c1dfac7494fa99f3d382cb91
Using lseek on 64-bit offset parameter caused failure
to write persistent data in crypto footer.
Changed calls to use lseek64 instead.
Change-Id: I4e4c397a6d36201b8b08be3017e17c9fac3b34e4
The structure crypt_persist_data was allocated,
but never freed.
Added free of allocated memory in normal and
error case.
Change-Id: I9aaa067e6f6501e8ce007f8659004b5dbcf2b246
Add maybeenabledefaultencryption function, that encrypts based
on the encryption flag and appropriate environment variable
Bug: 18764230
Change-Id: Id9a1967d09a7ae63a51240c0a5f3c41505af0e9a
The libcrypto and libssl modules (and their respective static and host
versions) use LOCAL_EXPORT_C_INCLUDE_DIRS thus just including the module
is sufficient.
Additionally, cryptfs.h was including an OpenSSL header just to get the
length of a SHA-256 hash. Rather than force all users of this header to
also depend on libcrypto, it's easier just to define that value in the
header file.
Change-Id: I3e3e0db906a212e1093944b298e4a8ff2e2fb07d
Add maybeenabledefaultencryption function, that encrypts based
on the encryption flag and appropriate environment variable
Bug: 18764230
Change-Id: Id9a1967d09a7ae63a51240c0a5f3c41505af0e9a
Since the dm_ioctl struct was being allocated on the stack as a large
character array, it was getting character alignment rather than the
proper alignment for the struct. GCC had been getting away with this
so far, but it's undefined behavior that clang managed to expose.
Bug: 18736778
Change-Id: Ied275dfad7fcc41d712b2d02c8a185f499221f57
-Wno-missing-field-initializers is used as well, but that is an
overzealous warning from initializing structs with {0} and not a
real warning.
bug 18736778 and 16868177
Change-Id: Iffde89cd7200d9a11193e1614f1819f9fcace30a
It looks like clang might have a miscompile that is causing SIGBUS in
`ioctl_init` when the device is encrypted. Move back to GCC until we
can sort this out.
Bug: 18736778
Change-Id: I21ae3b9d7d9ebff8679ecc1a828b7c59f27d0903
encrypt-and-wipe was broken when checks were added that encryption succeeded
which assumed a 'normal' full encrypt traversing the device.
encrypt-and-wipe doesn't traverse, it just lays down a file system over
the encrypted device, so in this mode do not check the amount encrypted -
it will always be 0.
Bug: 18511900
Change-Id: Icb1d7e0cdb67abd2eac0ab3cbfc1a88912768f9d
Nick Kralevich
Henrik Baard
Marek Pola
Elliott Hughes
Björn Landström
Paul Lawrence
Kenny Root
Adam Langley
Yabin Cui
Brian Carlstrom
Dan Albert
Tim Murray