Hello Laxman, I'm curious how this is a new problem after migration from HttpFs to WebHDFS. With the HttpFs deployment architecture, were you somehow proxying only the read-only operations?
I would think this kind of thing could be achieved by writing a custom authentication filter, deploying that to the HDFS classpath, and then pointing to it by setting dfs.web.authentication.filter in hdfs-site.xml to the full name of that custom authentication filter class. The logic of the custom authentication filter would check for only read-only operations and reject the others. This is a solution that wouldn't require changes in WebHDFS itself. This is not a requirement I've heard from anyone else. I'm generally reluctant to add features without a widespread need. Still, if you want to file an HDFS JIRA for further discussion of your proposal, there is no harm in that. It might end up as a "Won't Fix", or perhaps others in the community see it differently from me, and we'd want to proceed. Thanks for sharing the work you've done! --Chris Nauroth On 11/6/15, 3:02 AM, "Laxman Ch" <laxman....@gmail.com> wrote: >Hi, > >We run a cluster with security set to simple. >Also, to some users, we had provided http access to HDFS via HttpFS >gateways. >However, this is not scaling and we are suffering from HttpFs gateway >choking problem. So, we wanted to enable WebHDFS directly on hadoop. But >this brings in the problem of security. Any user can simply delete >anything. And, we can't enable immediately enable kerberos security in >production. > >How about introducing a configuration to make WebHDFS readonly? >We patched this in our clusters cleanly and its working. > >Please revert with your comments if its a good idea to push this to >hadoop. >If yes, I will create a jira and submit patch. >-- >Thanks, >Laxman
