
安全法规汇总
整理资料的时候,发现之前汇总过的一些安全法规,上次更新大概在24年中:



常见数据传输方式

编程范式

设计原则

设计模式


WSL2中apt升级systemd时报错:无法锁定passwd文件
1、环境:
Windows10+WSL2+Ubuntu24
PS:另一台电脑Windows11+WSL2+Ubuntu24,不会报错
2、再现方式及错误信息
# apt-get upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done ... ... Setting up systemd (255.4-1ubuntu8.8) ... Initializing machine ID from random generator. Failed to take /etc/passwd lock: Invalid argument dpkg: error processing package systemd (--configure): installed systemd package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1)
3、错误发生原因
systemd升级的脚本,会调用systemd-sysusers,systemd-sysusers会尝试通过fcntl锁定文件,但WSL中fcntl实现效果与Linux中不同,导致脚本执行失败。
更进一步的解释:
Linux中文件锁是基于文件描述符的,子进程会自动继承该文件锁。
Windows中文件锁是基于进程的,子进程需要自行获取新的文件锁。
WSL中,实现方式,更接近与Windows,重复获取同一个文件的锁自然是失败的。
openat(AT_FDCWD, "/etc/.pwd.lock", O_WRONLY|O_CREAT|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC, 0600) = 3
fcntl(3, F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = -1 EINVAL (Invalid argument)
4、如何绕过该错误
# 原文在此:https://github.com/microsoft/WSL/issues/10397
# 切换到/bin
# 将systemd-sysusers修改为systemd-sysusers.org
# 将systemd-sysusers做成一个echo的符号链接(用于欺骗升级脚本,让其以为得到了正确的结果)
# 切换回之前的目录
cd /bin && mv -f systemd-sysusers{,.org} && ln -s echo systemd-sysusers && cd -
# 修复包依赖
apt --fix-broken install
# 继续升级
apt-get upgrade
医疗大模型数据防护
医疗大模型训练数据,除了脱敏之外,至少还要做下面的工作
1、完整的医疗数据,即便做了基础的去标识化工作,也很容易反向推断定位到某个个体,所以要进一步加强:泛化(32岁改为30~40岁)、模糊、并引入噪声
2、医生不是神,并非所有的诊断都是对的、并非所有治疗方案都是最佳的,不合适的数据剔除很难
3、医疗数据的归属权有争议(极端一些,比如一个人在一家医疗机构做了全基因测序,测序结果是这家医疗机构的吗),需要获取患者授权,最好能给予收益分成
4、医学伦理、社会道德、大众接受程度这些问题,要考虑在前面
5、医疗数据在部分国家地区是不允许高度集中的,分散在各机构服务器中(医院、体检机构、公卫机构),所以要数据不动模型动,采用类似联邦学习的技术
医疗健康场景下Constitutional AI规则
1、生命优先,患者安全第一,推荐风险较低的方案,提醒及时就医
2、保持大模型的专业及严谨性,不得针对训练边界之外的病种给出建议,更不可随意发挥
3、医学建议要透明可解释,要能溯源到教材、规范、病例和高可信的论文等材料
4、大模型仅为辅助工具,关键节点包括处方、医嘱、手术等,最终决策权还给医生
5、尊重患者的尊严与自由
6、保护隐私,遵守相关法律
7、保障患者知情权,说明大模型的局限性及潜在风险
8、符合道德及医学伦理,公平无歧视
9、如果面向患者,那输出要更有温度,不要过于冷漠
记一次存储Inode数量引发的生产故障
前一段时间,突然收到了系统报警,某上传服务异常。
经过排查,上传服务正常,但存储无法正常写入,一直写入失败,表现为:
1、一块新盘,32T,已使用2T,可用30T,控制台和命令行操作结果一直
2、服务写入时,一直报“no space left on device”
3、没有收到任何存储报警
立刻找了云服务厂商的老师,解决了问题:
1、除了限制写入文件总量的大小、并发写入的速度,同时还限制了inode数量
2、上传服务,写入了大量小文件,耗尽了inode数量
3、上传服务,再次写入后,inode申请失败,导致写入失败
4、存储组的老师,紧急扩展了inode数量,解决了问题
经排查,云服务商反馈:
1、为了控制成本,我们之前买了一块较小的硬盘,然后进行了扩容
2、而存储的底层协议为FlexGroup
3、而FlexGroup的普通卷,在扩容的时候,只要超过了1T,默认的Inode数量就一直为21251126,不再提升
4、而我们的上传服务,一个小文件只有几百k,很快就把Inode数量耗尽了
5、对于Inode数量限制,云服务商没有提供任何监控
虽然FlexGroup的超大卷默认会提升Inode数量,但我们一开始购买的服务确是普通卷,然后进行扩容,扩容后仍是普通卷,就触发了Inode数量不会自动增加这个问题。
后续,我们做了两个约定:
1、尽量采购超大卷
2、如果要采购普通卷,同时提单,增加Inode数量
3、云服务商同步进行产品更新,后续产品迭代时,从根源上解决这个问题
PS:
最近发现,他们居然做了一个inode扩容的功能,默认是最小值,可以手工扩展,也能设置为自动扩展。
不知道是谁定的需求,默认选项不应该是自动扩展吗?