[ https://issues.apache.org/jira/browse/DRILL-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ehur updated DRILL-5565: ------------------------ Environment: CentOS release 6.8 > Directory Query fails with Permission denied: access=EXECUTE if dirN name is > 'year=2017' or 'month=201704' > ---------------------------------------------------------------------------------------------------------- > > Key: DRILL-5565 > URL: https://issues.apache.org/jira/browse/DRILL-5565 > Project: Apache Drill > Issue Type: Bug > Components: Functions - Drill, SQL Parser > Affects Versions: 1.6.0 > Environment: CentOS release 6.8 > Reporter: ehur > > running a query like this works fine, when the name dir0 contains numerics > only: > select * from all.my.records > where dir0 >= '20170322' > limit 10; > if the dirN is named according to this convention: year=2017 we get one of > the following problems: > 1. Either "system error permission denied" in: > select * from all.my.records > where dir0 >= 'year=2017' > limit 10; > SYSTEM ERROR: RemoteException: Permission denied: user=myuser, > access=EXECUTE, > inode: > /user/myuser/all/my/records/year=2017/month=201701/day=20170101/application_1485464650247_1917/part-r-00000.gz.parquet":myuser:supergroup:-rw-r--r-- > 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:6609) > at > org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getFileInfo(FSNamesystem.java:4223) > at > org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getFileInfo(NameNodeRpcServer.java:894) > at > org.apache.hadoop.hdfs.server.namenode.AuthorizationProviderProxyClientProtocol.getFileInfo(AuthorizationProviderProxyClientProtocol.java:526) > at > org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.getFileInfo(ClientNamenodeProtocolServerSideTranslatorPB.java:822) > at > org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) > at > org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:617) > at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1060) > at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2086) > at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2082) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1671) > at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2080) > 2. OR, if the where clause only specifies numerics in the dirname, it does > not blow up, but neither does it return the relevant data, since that where > clause is not the correct path to our data: > select * from all.my.records > where dir0 >= '2017' > limit 10; -- This message was sent by Atlassian JIRA (v6.3.15#6346)