CurveFs 用户权限系统调研CurveFs 用户权限系统调研(已实现) ## 一、 Curvefs测试 • 1. 启动curvefs • 问题1:root用户无法访问挂载目录 • 测试 allow root - 测试allow_other • 参考文献 - 问题2:本地文件系统挂载默认是共享的? - 问题3:文件系统访问控制是在哪一层实现的? ## 二、 文件系统权限管理 • 文件类型 • 文件权限 • 特殊权限 特殊权限 (SUID, SGID, STICKY) - 文件默认权限mask - 用户&用户组 - 文件系统用户权限管理 - 对mode的管理 - 对ACL(Access Control Lists)的管理 - ACL Access Entry保存在哪? • ACL的表示 • 内存中的ACL 是如何与具体的 Inode 相关联 • 如何存储和获取ACL信息 如何存储和获取ACL信息 • Inode权限校验 • chmod、chown、setfacl、getfacl接口文件系统自己如何实现 • 结论: • 参考文献: ## 一、 Curvefs测试 代码:https://github.com/cw123/curve/tree/fs_s3_joint_debugging 环境:test2 ### 1. 启动curvefs 手动创建c0 码力 | 33 页 | 732.13 KB | 1 年前3
01. 邓良驹 编写更安全的Python代码 如何尽量规避风险 1. 默认不相信外部输入,需要进行检查; 2. 内部逻辑也应该做检查,例如购买东西以后余额应该降低而不是升高; 3. 奥卡姆剃刀原则,用能达到目的的最简单的设计、配置,减少缺陷的可能性; 4. 最小权限原则,仅用恰好够用的权限去执行代码,减少越权漏洞; 5. 定时清理缓存数据,以及非业务代码的固有数据,减少入侵风险; 6. 在发布代码前,使用 Bandit 工具检查代码,规避最常见的不安全写法;0 码力 | 18 页 | 988.40 KB | 2 年前3
微服务的设计原则与⽣态系统 - 王磊## 微服务的设计原则 与生态系统 王磊 ## 关于我  Ruby Gems 开发实战  软件复用的最小粒度应等同于其发布的最小粒度。 ## CCP 共同闭包原则 (Common Closure Principle) 为了相同目的而同时修改的类,应该放在同一个模块中。对 模块中,那么开发、提交、部署的成本都会上升。 CRP 共同复用原则 (Common Reuse Principle) 不要强迫一个模块依赖它不需要的东西。  模块复用原则竞争关系张力图 ## 模块化设计-单仓包设计 ## module0 码力 | 37 页 | 8.84 MB | 2 年前3
Hermes-Agent-从入门到精通-v260407API,个人也能部署媲美商业方案的AI Agent。MIT许可证,完全开源。 他们的核心原则挺鲜明的。用户控制优先,模型是可控的(steerable),你可以按需调整行为,不受企业内容策略限制。审查这事儿他们明确不做,声明模型是「unencumbered by censorship, neutrally aligned」。同时在创造力和数学、编码、推理性能上都不妥协。 这些原则决定了Hermes Agent的设计取向:不是替你做决 itHub通知」,它就创建一个定时触发。不用写cron表达式,不用配调度器。 Toolset:不是全开,是按需启用 40+个工具全开不合理。帮你写代码的Agent不需要Home Assistant权限,管日程的Agent也用不到code_execution。 Hermes用Toolset机制解决这个问题。工具按功能分组,在config.yaml里按需启用或禁用: config.yaml 示例 toolsets: 的事然后汇总」。比如你让Hermes写一篇技术博客,它可能同时派一个子Agent调研最新资料、一个子Agent分析竞品文章、一个子Agent整理代码示例,最后主Agent把三方结果整合成初稿。 工具权限与沙箱:约束层的落地 前面几章讲了学习循环、记忆、Skill,都是让Agent变强的机制。但Agent越强,约束越重要。 Hermes在工具层面做了三重约束: Toolset控制。只有config.0 码力 | 63 页 | 7.25 MB | 2 月前3
云原生安全威胁分析与能力建设白皮书(来源:中国联通研究院)5:Serverless 攻击 ..... 33 2.6.1 事件注入攻击 ..... 34 2.6.2 敏感数据泄露攻击 ..... 34 2.6.3 身份认证攻击 ..... 35 2.6.4 权限滥用攻击 ..... 35 2.6.5 拒绝服务攻击 ..... 36 2.6.6 针对函数供应链的攻击 ..... 36 三、典型攻击场景分析 ..... 37 3.1 镜像投毒攻击 3.2 挂载 Docker Socket 导致容器逃逸攻击 ..... 38 3.2.1 攻击场景介绍 ..... 38 3.2.2 攻击过程复现 ..... 39 3.3 k8s 权限提升攻击 ..... 40 3.3.1 攻击场景介绍 ..... 40 3.3.2 攻击过程复现 ..... 41 3.4 Istio 认证策略绕过攻击 ..... 43 3.4.1 云原生运行时安全 ..... 56 4.2.3 网络微隔离 ..... 58 4.3 基础设施安全能力建设 ..... 59 4.3.1 基础设施即代码安全 ..... 59 4.3.2 权限管理 ..... 60 4.3.3 云原生安全态势 ..... 60 五、总结与展望 ..... 62 六、参考文献 ..... 64 ## 图 目 录 图 1 云原生四要素 ....0 码力 | 72 页 | 2.44 MB | 2 年前3
Greenplum Database 管理员指南 6.2.1解读 GP 分布策略..... -22 第三章:角色权限管理..... -24 角色与权限安全的最佳实践..... -24 创建用户 User Role..... -25 修改 ROLE 属性..... -25 创建用户组 Group Role..... -27 管理对象权限..... -28 模拟 Row 级别的权限控制..... -29 密码加密..... -29 -29 基于时间的登录认证..... -30 需要的权限..... -31 如何添加时间约束..... -31 第四章:配置客户端认证..... -34 允许连接到 Master..... -34 编辑 pg_hba.conf 文件..... -35 限制并发连接数量..... -36 客户端/服务端间的加密连接..... -37 第五章:访问数据库..... -39 .. -101 修改表定义..... -113 删除表..... -116 分区大表..... -116 理解 GP 的表分区..... -117- 决定表是否分区的原则.....-118 创建分区表.....-119 插入数据到分区表.....-125 验证分区策略.....-126 分区选择性的诊断.....-127 查看分区设计0 码力 | 416 页 | 6.08 MB | 2 年前3
共 970 条
- 1
- 2
- 3
- 4
- 5
- 6
- 97
相关搜索词
CurveFs权限管理allow_otherdefault_permissionsACL安全编码Python代码Bandit工具PyPI包最小权限原则微服务架构去中心化自动化一切交付流水线API网关单一职责原则开闭原则里氏替换原则接口隔离原则依赖倒置原则线性回归梯度下降误差函数最小二乘Stochastic Gradient DescentScrumLean政府SMART原则增量交付可交付成果模块化设计统一框架代码分层设计松耦合框架架构Hermes Agent学习循环三层记忆Skill系统MCP集成云原生安全容器化基础设施API安全制品安全运行时安全Greenplum Database升级安装架构管理节点













