HDFS 特殊权限位

时间:2019-10-31
本文章向大家介绍HDFS 特殊权限位,主要包括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控制。

原文地址:https://www.cnblogs.com/hit-zb/p/11771843.html