HDFS 特殊权限位

HDFS 特殊权限位

标签（空格分隔）： Hadoop

---

以前对HDFS更或者说是对Linux中文件的权限没有进行一个完整的学习，只是知道有全部者、所属组和其它权限，具体到某我的的权限有读(r)、写(w)和可执行(x)。

HDFS基于Linux的POSIX model

HDFS的权限虽然是基于Linux的POSIX model，可是HDFS中其实并无真正的用户和组的概念，只是从主机上拿到用户的信息而后对其存储的文件权限进行检查。

HDFS中每一个文件和目录都有一个owner和group，并对owner、owner同一个组的user和其它user的权限进行了分离，权限分为rwx。对于文件来讲，有r权限则可对此文件可读，有w权限则可对文件进行写和追加，x权限对文件来讲没有实际的意义。对于目录来讲，拥有r权限能够查看目录中内容，好比此目录下的文件或者子目录，拥有w权限能够在此目录中新建或者删除文件和子目录，但不能够改变此目录的名字，由于改变此目录的信息是须要其上层目录的写权限，对于目录来讲，我的感受最重要的应该是x权限，拥有x权限，才能够进入当前目录进行其它操做。

若是没有目录的x权限，你拥有的其它权限并不能发挥相应的做用，由于rw权限都是针对目录中的内容的，当你没有进入目录的权限时，其它权限都是虚无。

sticky bit

HDFS中还有一个sticky bit，此功能只针对目录有效，是一个防删除位。防止除管理员、目录或者文件的全部者以外的其它人(即便其它用户对该文件夹有rwx权限)对当前加了 sticky 位的目录或者当前加了 sticky 位的目录下的文件或者目录进行删除。
命令以下：

#即在第一位添加数字1
hdfs dfs -chmod 1777 /tmp
hdfs dfs -chmod 1777 /user/hive/warehouse
# 也能够
hdfs dfs -chmod +t /tmp
hdfs dfs -chmod +t /user/hive/warehouse

sticky bit
不一样于suid, guid，对于others的execute权限位，则能够设置sticky bit标志，
用t来表示，若是该位置原本就有可执行权限位，即x，则t和x叠加后用大写的T来表示。

sticky bit只对目录起做用，若是一个目录设置了sticky bit，则该目录下的文件只能被
该文件的owner或者root删除，其余用户即便有删除权限也没法删除该文件。

例如，/tmp目录，它的权限为d rwx rwx rwt，该目录中的文件(或目录)只能被owner
或root删除，这样你们均可以把本身的临时文件往该目录里面放，可是你的文件别人是没法
删除的。

注意：suid, sgid只对文件起做用，而sticky bit只对目录起做用。

HDFS ACL

HDFS ACL(Access Control Lists)是对POSIX permissions model的一个补充。传统的权限是针对用户和组的组织架构来设置的，但当你只想给特定的用户或者组(而不是只针对文件的全部者和所属组)来开权限时，咱们就可使用ACL来控制。

默认状况下，HDFS ACL功能是关闭的，由于开启ACL以后，NN中会对开启ACL的inode存储一份额外的数据，会带来额外的内存开销，若是有须要能够在hdfs-site.xml中设置dfs.namenode.acls.enabled为true。

新建一个文件或者目录时，会继承父目录的ACL，但改变父目录的ACL时，在此目录中已经存在的内容不会发生改变。

一个文件或者目录的ACL由一组ACL entry组成。每一个Entry标识一个用户或者组的rwx权限，以下一个文件的一个ACL：

user::rw-
user:bruce:rwx                  #effective:r--
group::r-x                      #effective:r--
group:sales:rwx                 #effective:r--
mask::r--
other::r--

文件的全部者具备rw权限，所属组具备rx权限，其它用户具备r权限，可是用户bruce具备该文件的rwx权限，sales组也具备该文件的rwx权限。可是bruce和sales就真的具备rwx权限了？这里还有最后一道防线mask，mask决定了一个用户或者组可以获得的最大的权限。上面的例子中，bruce和sales的权限会与mask的权限进行与运算，最终的结果才是bruce和sales的权限，也就是注释中的内容。

权限检查流程

当一个文件有ACL时，权限检查的流程为：

一，判断该用户是否为owner
二，判断该用户是否包含在ACL entry的user中，若是在，则经过mask过滤权限
三，判断该用户的所属组是否包含在组中，包含则也要经过mask来过滤权限(由于在使用了ACL的状况下，group的权限显示的就是当前的mask)
四，判断该用户的所属组是否包含在ACL entry的group中，若是在，则经过mask来过滤权限

ACL命令

# 添加用户acl
hdfs dfs -setfacl -m user:xx:rwx path
# 删除一个用户的acl
hdfs dfs -setfacl -x user:xx path
# 删除全部的acl
hdfs dfs -setfacl -d path
# 查看acl
hdfs dfs -getfacl path

目录或者文件添加了ACL以后，ll命令查看，会有一个+标识

umask

一个文件或者目录新建以后就有一个默认的权限，这个默认的权限是怎么控制的呢？是由umask控制的。

文件建立以后的默认权限是0666 & ^umask，目录建立以后的默认权限是0777 & ^umask，umask在core-site.xml中由fs.permissions.umask-mode设置，默认是022。

HDFS 开启权限

core-site.xml

core-site中主要是设置umask，由fs.permissions.umask-mode控制，默认是022

hdfs-site.xml

hfds-site中控制着权限的开启，参数以下：

dfs.permissions.enabled = true
是否开启权限检查，默认是true

dfs.permissions.superusergroup = supergroup
设置hdfs管理员的组名称，模式名字是supergroup，通常改成与管理员相同的名字，如管理员是hdfs，则改成hdfs

dfs.namenode.acls.enabled = true
控制ACL是否开启，默认为false。

Tips:HDFS权限设置最好是以传统的权限进行控制，只针对个别权限要求高的文件进行ACL控制。