Проблемы с разрешениями папки Папки при использовании Hive и Impala как

Question

Мы используем последние версии Hive, а также Impala. Импала аутентифицируется с помощью LDAP, и авторизация осуществляется через Sentry. Доступ к Hive еще не разрешен с помощью Sentry. Мы создаем таблицы из Impala, в то время как у/user/hive/storage есть группа на уровне группы «hive», поэтому разрешения на папку - impala: hive.

drwxrwx--T - impala hive   0 2015-08-24 21:16 /user/hive/warehouse/test1.db 
drwxrwx--T - impala hive   0 2015-08-11 17:12 /user/hive/warehouse/test1.db/events_test_venus 

Как видно, вышеуказанные папки принадлежат Impala, а группа - Hive и являются групповыми. Группа «улей» есть пользователь с именем «улей», а также:

[root@server ~]# groups hive 
hive : hive impala data 

[root@server ~]# grep hive /etc/group 
hive:x:486:impala,hive,flasun,testuser,fastlane 

Но когда я пытаюсь запросить таблицу, созданную папку, она дает ошибки доступа:

[root@jupiter fastlane]# sudo -u hive hive 

hive> select * from test1.events_test limit 1; 
FAILED: SemanticException Unable to determine if hdfs://mycluster/user/hive/warehouse/test1.db/events_test_venus is encrypted: org.apache.hadoop.security.AccessControlException: Permission denied: user=hive, access=EXECUTE, inode="/user/hive/warehouse/test1.db":impala:hive:drwxrwx--T 
    at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.checkFsPermission(DefaultAuthorizationProvider.java:257) 
    at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.check(DefaultAuthorizationProvider.java:238) 
    at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.checkTraverse(DefaultAuthorizationProvider.java:180) 
    at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.checkPermission(DefaultAuthorizationProvider.java:137) 
    at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:138) 
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkPermission(FSNamesystem.java:6599) 
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkPermission(FSNamesystem.java:6581) 
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkPathAccess(FSNamesystem.java:6506) 
    at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getEZForPath(FSNamesystem.java:9141) 
    at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getEZForPath(NameNodeRpcServer.java:1582) 
    at org.apache.hadoop.hdfs.server.namenode.AuthorizationProviderProxyClientProtocol.getEZForPath(AuthorizationProviderProxyClientProtocol.java:926) 
    at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.getEZForPath(ClientNamenodeProtocolServerSideTranslatorPB.java:1343) 
    at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) 
    at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:619) 
    at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1060) 
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2044) 
    at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2040) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at javax.security.auth.Subject.doAs(Subject.java:415) 
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1671) 
    at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2038) 

Любые идеи, как противостоять этому ?? В основном мы пытаемся использовать тот факт, что, предоставляя разрешения на чтение и запись на уровне группы, мы должны иметь возможность заставить любого пользователя группы создавать и использовать таблицы, созданные владельцем папки, но это не представляется возможным. Это из-за того факта, что у Импалы есть авторизация Sentry, которая использует имперсонализацию пользователя, а Hive - автономно?

Может кто-нибудь проконсультироваться?

Благодаря

Answer 1

Вы можете установить биты полномочий HDFS на 000 и перезапустить кластер. Это гарантирует, что все каталоги или файлы, созданные после этого изменения, будут иметь разрешения 777. После этого примените правильное владение и разрешения для каталогов и папок, чтобы гарантировать, что разрешения других каталогов не открыты. Установка umask на 000 не изменит разрешения существующих каталогов. Это повлияет только на созданные каталоги/файлы. Если вы используете менеджер cloudera, очень легко сделать это изменение.

NB: Umask 000 сделает все файлы/каталоги с разрешением 777 по умолчанию. Это сделает открытые разрешения. Поэтому справляйтесь с этим, применяя разрешения и acls на уровне родительского каталога.