[
https://issues.apache.org/jira/browse/KUDU-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785880#comment-17785880
]
ASF subversion and git services commented on KUDU-3520:
-------------------------------------------------------
Commit 1c5eb9f98d24b05cbafa596b964aae2ea831ad0f in kudu's branch
refs/heads/master from Attila Bukor
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=1c5eb9f98 ]
KUDU-3520 Fix file descriptor leak in encryption
In PosixEnv, when creating new file handles, file descriptors are
created first, which are then passed to file handle objects, which close
the file descriptors in their destructors. With encryption enabled,
things can go wrong before they're passed to these objects, in which
case the file descriptors can be leaked due to returning from these
methods without the file handle objects being created.
This commit fixes this leak by closing the files on the failure cases.
Unfortunately, I couldn't reproduce the bug reported originally after
several attempts with different fd limits as if it was set too low, it
failed with a different error, and if it was set higher, it just didn't
fail. It looks like this was an edge case triggered by an unhappy
coincidence of multiple variables.
Change-Id: I2412429d4fe836b705296e9e30453d7c4d030cec
Reviewed-on: http://gerrit.cloudera.org:8080/20631
Reviewed-by: Alexey Serbin <ale...@apache.org>
Tested-by: Kudu Jenkins
> File descriptor leak in Env::NewRWFile() when ecryption-at-rest is enabled
> --------------------------------------------------------------------------
>
> Key: KUDU-3520
> URL: https://issues.apache.org/jira/browse/KUDU-3520
> Project: Kudu
> Issue Type: Bug
> Components: fs, security, tserver
> Affects Versions: 1.16.0, 1.17.0
> Reporter: Alexey Serbin
> Assignee: Attila Bukor
> Priority: Major
>
> There is a file descriptor leak in {{Env::NewRWFile()}} on an error path when
> encryption-at-rest is enabled.
> In the code below, if {{ReadEncryptionHeader()}} or
> {{WriteEncryptionHeader()}} failed, the descriptor of the file opened by
> {{DoOpen()}} would be leaked.
> {noformat}
> RETURN_NOT_OK(DoOpen(fname, opts.mode, &fd));
> EncryptionHeader eh;
> if (encrypt) {
> DCHECK(encryption_key_);
> if (size >= kEncryptionHeaderSize) {
> RETURN_NOT_OK(ReadEncryptionHeader(fd, fname, *encryption_key_, &eh));
> } else {
> RETURN_NOT_OK(GenerateHeader(&eh));
> RETURN_NOT_OK(WriteEncryptionHeader(fd, fname, *encryption_key_, eh));
> }
> }
> result->reset(new PosixRWFile(fname, fd, opts.sync_on_close, encrypt,
> eh));
> {noformat}
> It's been evidenced in the wild when creating the metadata file for a tablet
> during tablet copying failed with the error like below:
> {noformat}
> Runtime error: Couldn't create tablet metadata: Failed to write tablet
> metadata d199a872b03848d695f067ed5c694835: Failed to initialize encryption:
> error:0607B083:digital envelope routines:EVP_CipherInit_ex:no cipher
> set:crypto/evp/evp_enc.c:170
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
