对文件目录设置acl权限
发表于|更新于
|浏览量:
尽管 sudo 可以设置某个用户有特殊权限,确实会增大这个用户的权限。
为了限制这个特殊目录只有特定用户可以读,您可以对特殊用户设置目录访问控制列表 acl。
以 user 用户为例,这样设置之后可以实现只有 user 用户可以对这个目录有读权限,其他普通用户无权限
setfacl -m u:user:r– /目录名/文件名
如果想要一次设置可以添加 -R 参数 递归设置整个目录,以及整个目录下的所有文件
setfacl -R -m u:user:r– /目录名/
这样就可以保证某个特殊普通用户对这个目录有可读权限
如果这个目录需要 user 用户可以 cd 进入的话,设置时可以增加大写 X 参数,设置 acl 的时候,大写 X 表示遇到目录给执行权限,遇到文件对象不给执行权限
setfacl -m u:user:r-X /目录名/
setfacl -m u:user:r-X /目录名/文件名
这样设置,可以让 user 用户能 cd 进入特殊目录
文章作者: Michael Pan
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Michael Blog!
相关推荐
2020-05-20
OpenShift生产集群物理机部署与虚拟机部署各自优缺点
OpenShift是物理机部署,还是虚拟机部署?这是企业在做容器平台架构选型时必须考虑的问题。尤其是大企业,有机器,有业务。今天我们就来列一列物理机与虚拟机部署各自的优缺点。 物理机部署 优点 性能好,无虚拟化层性能开销 小业务集群,节点少 配置高能够支持更大规模的容器数量 License成本更低 架构复杂度低(PaaS) 需要额外准备LB与存储 缺点 运维复杂度高 集群扩容周期长 如果出现故障,恢复周期长,需要及时去机房诊断修复 一台主机出现故障,影响业务范围更广 合规限制,需要更高要求的安全与隐私控制 虚拟机部署 优点 灵活部署、配置、维护简单 快速扩容 能与IaaS资源混合使用(LB、存储等) 一台虚拟机出现故障,影响业务范围小 虚拟机技术成熟,有热迁移技术,恢复快 IaaS高可用+PaaS高可用,两层保障 虚拟机支持虚拟快照,方便做主机回滚,集群可靠怀提升 IaaS目前已经有成熟的合规方案,在其上构建PaaS可以更方便地满足合规要求 缺点 性能较差(网络、计算等) 架构复杂度提升(IaaS + Paas) 配置较低,承载的容器容量更小(节点更多) 需要...
2020-05-20
OpenShift中如何将PV与PVC绑定
PV/PVC是什么?PV(Persistent Volume):描述的是持久化的Volume实体概念,生命周期与Pod创建和销毁事件无关。要么运行事先准备好,要么通过动态创建。PVC(PersistentVolumeClaim):PVC是对PV的请求,申明Pod所希望使用的持久化存储的属性,例如容量,读写权限。 Kubernete Volumes能够帮忙应用持久化数据,PV/PVC是Kubernetes Volumes存储类型的一种,其它类型还有:本地存储:emptyDir / hostPath网络存储:in-tree: aws ElasticBlockStore / gcePersistentDisk / nfsout-of-tree:csi等网络存储插件Project Volume:secret / configmap / downwardAPI / serviceAccountToken PV/PVC的意义 使用不同的控制器来管理计算与存储资源,解耦POD与Volume的生命周期,实现...
2020-05-20
OpenShift灾备的方案及步骤
https://docs.openshift.com/container-platform/3.11/admin_guide/assembly_restoring-cluster.htmlhttps://docs.openshift.com/container-platform/3.11/admin_guide/assembly_replace-master-host.htmlhttps://docs.openshift.com/container-platform/3.11/admin_guide/assembly_restore-etcd-quorum.htmlhttps://docs.openshift.com/container-platform/3.11/admin_guide/assembly_replace-etcd-member.html

2020-05-20
OpenShift-集群为项目提供专属节点
背景介绍在生产实践中,某些系统因一些特殊的要求,需要独占节点,即专属节点:具有特殊要求的应用POD必须运行在这些专属节点上;同时这些节点不为其它应用服务。本文将提供一种具体的配置策略,以满足这种特殊的调度需求。该策略主要使用到两种工具: 节点标签实现应用与节点的绑定 污点配置实现其它应用不会被调度到该节点。 设置步骤 为专属节点设置特定标签LABEL:dedicated=sys0,及设置污点 12$ oc label node node-10 dedicated=sys0$ oc adm taint nodes node-10 dedicated=sys0:NoSchedule 在使用专属节点的应用编排中绑定的Node 123456789101112spec: replicas: 1 template: metadata: name: nginx labels: app: nginx spec: nodeSelector: dedicated: "sys0" ...
2020-05-20
Openshift排错技巧——From-Redhat大客户交流会
今天参加Redhat大客户交流会,有一个主题是Redhat的小伙伴介绍Openshift的排错技巧。这个还是很值得参考的,于是将内容发在了这里,以便更多的小伙伴能够从中受益。当然Redhat小伙伴列出的也只是一部分,同时有些排错细节PPT中也并没有具体写,这篇中我就不扩展了。以下为PPT的内容。 OpenShift排错技巧 环境基本信息收集 日志等级 应用程序 OC客户端排错 镜像仓库 网络 路由 Installer DNS Etcd 日志等级openshift service log:/etc/origin/master/master.env #同时作用于API和ControllersDEBUG_LOGLEVEL=4 /etc/sysconfig/atomic-openshift-nodeOPTIONS=–loglevel=4 错误等级 0 - Errors and warning only 2 - Normal information 4 - Debugging-leve...
2020-05-20
OpenShift-Prometheus使用集群外部Prometheus级联的方法实现多集群统一监控告警
背景大家知道OpenShfit官方通过Prometheus Operator可以快速构建高可用的监控告警平台,它不仅能够收集集群本身的监控指标,还可以通过ServiceMonitor扩展以监控应用自身的指标,实现单集群内部的统一监控。但是生产实践中,我们并不会只采用一个OpenShift部署应用,还会部署非容器应用,在非容器环境下也可能会部署Prometheus来监控相关服务(特别是现在Prometheus已经成为了监控的一个标配),甚至有可能会在不同的网络区部署多个集群,由于不同网络的隔离特性显然一组Prometheus是无法满足所有平台及应用的监控的。这就使得生产中会有很多套Prometheus集群需要管理与维护,查看监控指标也很分散,也就让我们想到必须采用一种办法能够将各处的指标统一收集,实现多集群多Prometheus服务的统一监控。目前实现这种要求的方法主要有两个,一个是通过Prometheus联邦 Federate,另一个是通过Thanos。今天主要介绍集群外部如何使用Prometheus联邦机制收集OpenShift内部Prometheus服务的监控指标。 操作实...
