关于hadoop中api在没有用户密码的情况下，拿到用户权限的思考

这边是最近学习遇到的一个问题，这边将这个问题进行一个重现：

        简单来说就是，hadoop使用api操作的时候，在代码中是出现了这个hadoop的用户名的（没有密码），然后它可以拿到一个对应的权限，对这个hadoop的资源进行一个相对应的一个操作。如果是root那就基本上是想干啥就干啥了，然后就会出现一个问题。

        如果说别人知道了你的这个hadoop的namedate 的ip地址的话，那岂不是想对你集群干啥都可以，所以我下面会对我的问题进行一个猜想性的解决，因为网络上对于这个的资料实在是太少了，我查了好久，查到的东西不多，下面会进行一个汇总。

        结果不一定对，如果有错还欢迎指出，这边做一个修改！！！

        首先我们先梳理一下对于hadoop的这个api的这个功能是怎么实现的。

首先：

        9000端口是在hadoop2.x中将FileSystem通讯端口拆分出来了，默认为9000，在hadoop2.x中我们可以在hdfs-size.xml中进行配置(就是hdfs客户端访问hdfs集群的RPC通信端口)

        RPC（Remote Procedure Call）是远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。简单的理解是一个节点请求另一个节点提供的服务

        RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

        RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。

        而至于为什么要去使用一个rpc服务的话，这边简单的提一下，主要是针对一个比较大的系统的时候，当我们要去优化一个组件的时候，可以对于这个组件进行一个单独的更新，前提是已经抛弃了老旧的开发模式，这个主要是针对模块化开发更新主键来说的。

        然后现在我们这个hadoop服务端这方面应该说的差不多了，接下来就是服务器。

        Hadoop有1个抽象的文件系统概念，HDFS只是其中一个实现。该抽象文件系统由抽象类org.apache.hadoop.fs.FileSystem 定义，该类继承了org.apache.hadoop.conf.Configured类，并实现了java.io.Closeable接口。 该抽象类类提供了丰富的方法用于对文件系统进行操作，比如创建目录、删除文件、重命名等。

        FileSystem抽象类的一个针对于分布式文件系统的实现子类，该类实现了DFS系统，通过该类用户代码与HDFS交互。

        对于这个FileSystem的类的实现，这边也简单的提一嘴，首先第一次进入程序，拿到对应的配置信息，然后利用这个配置信息去get一个对象，如果没有用户名的话，默认是获取当前操作系统的用户信息，接着是加载用户的相关信息，加载完以后再去实例化这个文件系统。文件系统拿到以后就是对相应的操作了。

        然后可能有的人会说，你说了这么多，也没有解决啊！别急，下面才是我的猜想：

因为这个过程中根本没有涉及一个密码的设置，所以我是不是可以认为在api的权限认证方面，压根就没有进行一个认证，也就是说他的认证方法是非常鸡肋的，而且在权限方面他引用了类似于linux的文件权限标识，所以我认为hadoop的权限是为了限制不同用户管理自己的文件夹而不穿错信息 ，所以这就会造成一个非常严重的安全问题，查了一些其他文章，他们似乎已经直接放弃了hadoop的权限认证，转而使用借助kerberos以及sentry等安全框架来管理大数据集群安全。

以上都是初学hadoop的一些猜想，欢迎指出相应的错误，学习的路上一起进步奥！！！

一些好的资料放在这里：

资料1

资料2