Re: Not Following POSIX ACLs

[Carlo Wood]

I must admit that I never heard of setfacl before, is that different
from chmod?

Nevertheless, as which prints:

/usr/bin/which: no hive in 
(/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin)

it is not in your PATH (the current directly, where hive is,
is /usr/hdp/current/hive-client/bin ... So, I'm not surprised
that GNU which doesn't find it, but I *am* surprised that bash
find it. Can you also include the output of 'which which' please?

On Mon, 08 Feb 2016 11:31:39 -0500
Sean Elble <address@hidden> wrote:

> Hi,
> 
> I ran into an odd issue this morning that surprised me, in that
> "which" doesn't seem to respect or follow the POSIX ACL bit.  For
> example:
> 
> address@hidden ~]# cd /usr/hdp/current/hive-client/bin
> address@hidden bin]# setfacl -m u:hive:rx hive
> address@hidden bin]# ll hive
> -rwxr-x---+ 1 root root  578 Sep 23 22:06 hive
> address@hidden bin]# su - hive
> -bash-4.1$ which hive
> /usr/bin/which: no hive in 
> (/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin)
> -bash-4.1$ hive
> 16/02/08 10:43:53 WARN conf.HiveConf: HiveConf of name 
> hive.optimize.mapjoin.mapreduce does not exist
> 
> In short, I removed the all other permissions from the file, allowed
> the "hive" user to read and execute
> "/usr/hdp/current/hive-client/bin/hive", and though the "hive" user
> can indeed execute the binary (as allowed by POSIX ACL), "which" does
> not recognize it as an executable file for this user.
> 
> Somewhat surprisingly, I haven't found anyone else reporting this
> issue in searching around a bit, but perhaps my Google-fu is failing
> me on what is very much a Monday morning.
> 
> Can anyone shed some light on this?  Is this something that is
> supported or may be supported at some point?  Please do CC me on
> replies, as I am not subscribed to this list.
> 
> Thanks,
> 
> Sean Elble
> 



-- 
Carlo Wood <address@hidden>