You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "lujie (Jira)" <ji...@apache.org> on 2022/10/10 07:34:00 UTC

[jira] [Comment Edited] (HADOOP-18235) vulnerability: we may leak sensitive information in LocalKeyStoreProvider

    [ https://issues.apache.org/jira/browse/HADOOP-18235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614935#comment-17614935 ] 

lujie edited comment on HADOOP-18235 at 10/10/22 7:33 AM:
----------------------------------------------------------

Hi: [~clayb] 

Thanks for fixing this bug. It looks good.  I also want to give another reason that we need to fix this bug.

Now the file is created by getOutputStreamForKeystore. The  permission of new file is afftected by umask. Assume that umask is 277, then the permission can 500 and we could not write the file.  Your patch can avoid such problem.


was (Author: xiaoheipangzi):
Hi: [~clayb] 

Thanks for fixing this bug. It looks good.  I also want to give another reason that we need to fix this bug.

Now the file is created by getOutputStreamForKeystore. The  permission of new file is afftected by umask. Assume that umask is 277, then the permission can 500 and we could not write the file.  Yours patch can avoid such problem.

> vulnerability:  we may leak sensitive information in LocalKeyStoreProvider
> --------------------------------------------------------------------------
>
>                 Key: HADOOP-18235
>                 URL: https://issues.apache.org/jira/browse/HADOOP-18235
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: lujie
>            Assignee: Clay B.
>            Priority: Critical
>
> Currently, we implement flush like:
> {code:java}
> //  public void flush() throws IOException {
>     super.flush();
>     if (LOG.isDebugEnabled()) {
>       LOG.debug("Resetting permissions to '" + permissions + "'");
>     }
>     if (!Shell.WINDOWS) {
>       Files.setPosixFilePermissions(Paths.get(file.getCanonicalPath()),
>           permissions);
>     } else {
>       // FsPermission expects a 10-character string because of the leading
>       // directory indicator, i.e. "drwx------". The JDK toString method returns
>       // a 9-character string, so prepend a leading character.
>       FsPermission fsPermission = FsPermission.valueOf(
>           "-" + PosixFilePermissions.toString(permissions));
>       FileUtil.setPermission(file, fsPermission);
>     }
>   } {code}
> we wirite the Credential first, then set permission.
> The correct order is setPermission first, then write Credential .
> Otherswise, we may leak Credential . For example, the origin perms of file is 755(default on linux),  when the Credential  is flushed, Credential can be leaked when 
>  
> 1)between flush and setPermission,  others have a chance to access the file.
> 2)  CredentialShell(or the machine node )  crash between flush and setPermission,   the file permission is 755 for ever before we run the CredentialShell again.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org